Jon, how do you continuously make a fast product, faster? Like, really, what goes into it?
Dev Build 3029
No, seriously, howâd you make it that much faster to startup? Iâm quitting and restarting all the time just for fun.
Actually, Iâm quite interested in this as well. I have so far been unable to access anything online through python on my work PC, including Package Control. So far, the auto-update and update checks are the only connectivity that has workedâŚ
My ST3 doesnât doesnât detect the update, is it working for you ?
startup, version: 3028 windows x64 channel: dev
[quote=âbizooâ]My ST3 doesnât doesnât detect the update, is it working for you ?
startup, version: 3028 windows x64 channel: dev[/quote]
I manually ran the âCheck for updatesâŚâ option under the âHelpâ menuâŚ
the startup time has become so fast that i think itâs unbelievable that the 99% of other apps are so slow!
here everything works fines⌠also the Package manager (iâm using Git trunk)
[quote=âjbjornsonâ]
[quote=âbizooâ]My ST3 doesnât doesnât detect the update, is it working for you ?
startup, version: 3028 windows x64 channel: dev[/quote]
I manually ran the âCheck for updatesâŚâ option under the âHelpâ menuâŚ[/quote]
Done that, but âno update availableâ.
It worked flawlessly with previous updates.
I wasnât happy with startup times on my OS X dev machine last week, so I spent some more time looking at it. Startup speed with ~500 files open was about 450ms, which is just enough to feel slow.
After some profiling, the culprits were:
- Font rasterisation. When creating fonts, the ASCII glyphs were eagerly cached, allowing faster lookups (array lookup vs hash table lookup for non-ascii glyphs). The faster lookup is important, but the eager glyph creation isnât: for the cost of one well predicted branch, the ASCII glyphs can be lazily generated. This alone saved about 80ms of startup time for my test case.
- Additional laziness during session restore. Moved some work that was being done per-file during session restore to be done once at the end of session restoration. Saved a small amount of time.
- Faster settings lookup. An unexpectedly large amount of time was being spend applying settings to view objects. Firstly, it was being done too frequently, so I reduced that. The next item was that each lookup was triggering a memory allocation, which is a common pitfall of using a std::map in C++ keyed by strings. Fixing that helped a little too.
After the above and a few other things, the test case went from ~450ms to a bit above 300ms. Aside from the font rasterisaion changes, most of the improvements should only be important if you have a large number of files open. Last time I was benchmarking startup times, it was with a much smaller number of open files, and the ASCII glyph lookup optimisation hadnât been implemented.
You should generally see better numbers than 300ms for a warm startup, for example, on my Windows dev machine, which has much less than 500 files open, startup times are around 80ms.
We use wininet.dll on Windows, which is AFAIK the same mechanism that Internet Explorer uses. It supports whatever proxy settings the system is setup with, including any crazy proxy auto configuration. NSURLConnection is used on OS X, which also makes use of the system proxy settings.
[quote=âbizooâ]
I manually ran the âCheck for updatesâŚâ option under the âHelpâ menuâŚ
Done that, but âno update availableâ.
It worked flawlessly with previous updates.[/quote]
jps, do you need some info to debug this ?
Otherwise Iâll download the install from the website.
Looking at the console (3028), I noticed these lines:
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
unknown include #documentation
launching: /C/Program Files/Sublime Text 3/plugin_host.exe
Look like itâs before the plugins are loaded, so it probably come from core ST3.
[quote=âwuubâ]
thedailywtf.com/Articles/The-Speedup-Loop.aspx ;)[/quote]
So that means we can look forward to further speed-ups thanks to premature de-optimizationâŚ
[quote=âadzenithâ]
Are they fixed? Iâve just updated to itâŚ[/quote]
Me too.
3030 is out now, which should fix the crash associated with theme reloading introduced in 3029.