Scrolling performance noticeably worse on retina Mac

[njx]

This is in current master (with CEF 3.1547.1337)

1. Open Activity Monitor
2. Launch Brackets pointing to the brackets repo
3. Open brackets.js
4. Wait for the process to go down to <1% CPU usage
5. Using the touchpad, throw scroll up and down
6. Compare with the same steps in Sprint 27

Result: In the latest version, scrolling is noticeably worse than in Sprint 27 even on a short file--it's very jerky. If you look at Activity Monitor, you'll see that with the current CEF, there are two Brackets Helper processes, and while scrolling, one of them averages 90-100% CPU usage and the other averages about 20%. In Sprint 27, there was only one Brackets Helper process, and during the same kind of scrolling it averaged about 50% CPU usage.

[njx]

FWIW, while I was reproducing this, there was a separate Chrome process (from my browser, unrelated to Brackets) taking up ~50% CPU. Without it, the difference in lag was less noticeable, but the CPU usage difference was still there. So I think there's a real issue here, but it will mostly be visible if something else is also using significant CPU resources.

[peterflynn]

Rendering performance has dropped dramatically on very old hardware btw -- I have a first-gen Mactel (Core 1 Duo with 10.6), and many operations are almost unbearably laggy with the new shell. It's very old hardware (2007??), so I don't think we should be worried per se -- but it's another indicator how much the render pipeline has changed in Chromium now.

[jasonsanjose]

I'm seeing a similar scrolling slowdown compared to Sprint 27, but I'm using today's build cef-3.1453.1279-v8-crash-redux8525. Since both versions are using the same build of CEF 3.1453.1279, I'm starting to think something else has changed.

Sprint 27: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Brackets/0.27.0 Safari/537.36"
Sprint 28: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Brackets/0.28.0 Safari/537.36

[jasonsanjose]

Reviewed. Assigned @njx medium priority.

[Globegitter]

Not sure if that is entirely related to the retina macbook, but sometimes scrolling can be a bit laggy for me and in a bigger sized project the Cmd + Shift + O command is really slow. Even after the new caching in Sprint 36 should have already kicked in.
That is really one of my only major issues so far, that performance doesn't seem to be comparable yet to Sublime Text.

[tkislan]

sprint 38 experimental build 0.38.0-12606 (release 4df8afd)
I can confirm that scrolling through file that has barely 500 lines, can cause CPU usage to go to 100% (one full core), this is just unacceptable
This makes this application unusable on laptop, as it devours the whole battery

[njx]

@tkislan I can reproduce that if I continuously scroll for a long period. However, doing the same test in Sublime Text shows over 50% CPU usage. So we're definitely worse by a factor of 2, but not an order of magnitude. That suggests to me that we have a decent chance of improving the CPU usage to more acceptable levels with the same optimizations that would make scrolling smoother, if we can find any.

[tkislan]

Was just trying the exact same thing, on the exact same project
I couldn't get Sublime on more than 30% CPU
Light Table is around 50%
But Brackets is taking alot more

[njx]

Yeah, Sublime is definitely more efficient generally - I can get it to 50% by throw scrolling a lot, but normally it hovers around 20-30%, whereas Brackets hovers around 60-70% and gets up to 100% if I keep going. Still, it doesn't seem so far out of whack as to be unfixable.

[njx]

(Having done a little profiling on the CodeMirror side, it seems like CM might be doing more style invalidation/repaints than necessary in some cases, so I think there might be some moderately low-hanging fruit there.)

[tkislan]

But I still prefer Brackets, as it handles the code intel automatically, compared to Sublime, where I cant get it to do it at all

So if you need any hand with debuging, Im eager to help

[njx]

Thanks. We do have scrolling performance on our near-term backlog (along with other perf issues), so hopefully we'll be able to make some progress in improving this within the next few releases.

[njx]

Leaving unassigned since this is on the backlog already.