Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explorer rendering is slow #18178

Closed
jrieken opened this issue Jan 5, 2017 · 3 comments
Closed

Explorer rendering is slow #18178

jrieken opened this issue Jan 5, 2017 · 3 comments
Assignees
Labels
info-needed Issue requires more information from poster perf
Milestone

Comments

@jrieken
Copy link
Member

jrieken commented Jan 5, 2017

re #15455

CPU-20170105T174926.cpuprofile.zip

@jrieken jrieken added the perf label Jan 5, 2017
@bpasero bpasero added this to the January 2017 milestone Jan 5, 2017
@bpasero
Copy link
Member

bpasero commented Jan 12, 2017

@jrieken I am not seeing the same or any significant amount of time spend in the labels when I run. The labels should not have an impact on the number of folders expanded because they only kick in to the visible viewport of the tree. I also see some viewlet unrelated times in that profile (spawn, JSON??)

Attached is a trace of expanding every folder in the extensions directory of our source tree (including all of node_modules which gives a large test set).

Most of the time is spend in paths.isEqualOrParent which I am able to fix. Looking at the second trace (after my fix), most time is imho spend resolving files from disk and updating the tree (which is #18180).

Before:
CPU-20170112T081858_before.cpuprofile.zip

After:
CPU-20170112T081926_after.cpuprofile.zip

@bpasero bpasero added the info-needed Issue requires more information from poster label Jan 12, 2017
@bpasero bpasero modified the milestones: Backlog, January 2017 Jan 12, 2017
@jrieken
Copy link
Member Author

jrieken commented Jan 12, 2017

I drilled very deep into the setInput and expandAll call found the renderer to take time (apart from the tree burning time). Unsure where I have seen the 200ms but I see this (in the original trace). Also looking in the traces

screen shot 2017-01-12 at 10 35 19

@jrieken
Copy link
Member Author

jrieken commented Jan 12, 2017

Yeah, unsure where that time came from. With newer version I don't see it anymore. Maybe some dom-distorition effects?

@bpasero bpasero closed this as completed Jan 23, 2017
@bpasero bpasero modified the milestones: January 2017, Backlog Jan 23, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
info-needed Issue requires more information from poster perf
Projects
None yet
Development

No branches or pull requests

2 participants