Sublime Forum

Dev Build 3029

#1

Dev Build 3029 is out now. There isn’t a huge amount of new things, but I’m hopeful it will fix the Linux issues introduced with 3028.

0 Likes

#2

This is my first try with the new auto-updater (windows 64-bit portable)…very cool and blindingly fast! Also nice to see the changelog being opened up in a new window :smile:

0 Likes

#3

New startup speed is quite impressive. It’s like night and day in my case compared to older builds.

0 Likes

#4

Jon, how do you continuously make a fast product, faster? Like, really, what goes into it?

0 Likes

#5

How’s the autoupdater dealing with proxies? Does it read env vars?

0 Likes

#6

No, seriously, how’d you make it that much faster to startup? I’m quitting and restarting all the time just for fun.

0 Likes

#7

Holy… doing the same here.

0 Likes

#8

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…

0 Likes

#9

thedailywtf.com/Articles/The-Speedup-Loop.aspx :wink:

0 Likes

#10

My ST3 doesn’t doesn’t detect the update, is it working for you ?
startup, version: 3028 windows x64 channel: dev

0 Likes

#11

[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…

0 Likes

#12

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)

0 Likes

#13

[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.

0 Likes

#14

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.

0 Likes

#15

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.

0 Likes

#16

[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.

0 Likes

#17

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.

0 Likes

#18

[quote=“wuub”]

thedailywtf.com/Articles/The-Speedup-Loop.aspx ;)[/quote]

:slight_smile:

So that means we can look forward to further speed-ups thanks to premature de-optimization…

0 Likes

#19

There are issues with this build, I’ve taken it down for the moment.

0 Likes

#20

Are they fixed? I’ve just updated to it…

0 Likes