Fix startup speed #2747
Fix startup speed #2747
Conversation
Avoid recomputing margin widths 2 or 3 times when initially creating the editing widget. As computing the margin widths might be costly, this can make widget creation about twice as fast. Part of #2649.
Computing the line height is a very costly operation that involves font loading and measuring, but the value stays mostly the same over time, as it depends on font, zoom and a couple other style settings which rarely change. As line height used to compute margin widths dominates startup timings, we now cache the latest result. This caching makes line height computation barely noticeable in startup times now. Fixes #2649.
It voids any kind of clashes, and is possibly easier to understand. It results in a slight memory overhead sorting a little more cache data, but it should not matter much here.
|
If this proves not to cause issues (it really shouldn't), it's possibly candidate for a 1.37.2. Opinions? @elextr @eht16 @codebrainz |
|
I think releasing it is a good idea. Basically, I wouldn't mind whether we call it 1.37.2 or 1.38 except that just "ctags_sync" has landed. So yes, 1.37.2 seems sensible. |
|
Given the "only" other change is we have a new ctags and it sounds like mid march before release and we havn't broken GTK2 (yet) I'd say call it 1.37.2. |
I don't think I'm gonna put the new ctags in a point release; although it's fairly minor from a user perspective, I'm not very comfortable pretending a +30k -7k change still is 1.37. |
Well branch the 1.37.2 off the commit before ctags maybe. |
Dynamic margin width computation introduced in 1.37 is "slow", and can lead to about 3× slowdowns, which is most noticeable when loading startup files.
Fixes #2649. Probably fixes geany/geany-osx#20 as well.
This PR is mostly FTR and to let @techee check on OSX, there has already been some review and testing (see commit comments and comments starting at #2649 (comment)). But more reviews & tests are welcome of course.