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 https://github.com/geany/geany-osx/issues/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 https://github.com/geany/geany/issues/2649#issuecomment-774309595). But more reviews & tests are welcome of course.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2747
-- Commit Summary --
* Avoid redundant margin computation when creating a new Scintilla widget
* Aggressively cache line height for computing margin sizes
* Use plain comparison instead of naive hashing
-- File Changes --
M src/editor.c (18)
M src/sciwrappers.c (39)
-- Patch Links --
https://github.com/geany/geany/pull/2747.patchhttps://github.com/geany/geany/pull/2747.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2747
After upgrading to 1.37-2 the startup with about 20-30 files takes ~10s on my 10.15,7 -- before it was <<5s
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/20
The Erlang programming language promotes the handling of functions deconstructing the arguments in different clauses. Its the natural way of the language. Its so common.
Most modules end-up with functions like these:
handle_call({hora, Persona}, _, State=#{persona_oper:=PersonaOper,
schedule:=Schedule}) ->
...
handle_call({head, Operador}, _, State=#{oper_persona:=OperPersona,
schedule:=Schedule}) ->
...
handle_call(active_heads, _, State=#{oper_persona:=OperPersona,
schedule:=Schedule}) ->
...
That whole pattern is just one function and each clause looks like any other function definition. Sometimes these functions tend to get big, as in any language depending of the problem they solve...
The SYMBOLS panel displays this clauses as:
https://imgur.com/S4gy2sc.png
As you can see the panel lists the clauses but then it doesnt give any lights about the function anymore. Thats a hole of information right there, whenever I'm analyzing these clause functions I just begin to strugle with exploring the code
Is there a way to tune the panel to list the complete line or maybe cut it but list them in raw so now they can present the information transparently?
For example
handle_call({hora, Persona}, _, State=#{pe... [203]
handle_call({head, Operador}, _, State=#{.... [212]
handle_call(active_heads, _, State=#{oper_... [219]
Most functional languages' function definitions tend to promote this pattern of development so their syntax in this aspect are quite refined. There is no need for cute visuals when the syntax is expressive enough, which is the case here.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2746
The hash thing would be a good idea if you were going to store a number of heights in a hash table, but you still have to store the original values in the table to check for hash clashes, and Geany's most common use-case (AFAIK) has all scintilla settings the same so a single cache is sufficient.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/commit/b08ae0fe65c0942dca20281d6841dc83406d8…
> Why do you need prev + old ones?
I meant prev + current, sorry. But my point was just that the test was gonna be verbose, plus that it would have memory overhead (at the benefit of robustness).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/commit/b08ae0fe65c0942dca20281d6841dc83406d8…
@elextr here you go: f600937dd8f592ff00150867537166b2d86aa4dd.
It's more verbose, but possibly easier to grasp, and indeed doe snot suffer from hash clash. And although it's using a lot more memory it should still be reasonable (`sizeof(void*) + strlen(font) + 2 + 3*sizeof(int)`, plus any padding in struct and font string allocation instead of `sizeof(int)`, which with the font "monospace" is gonna be 31 bytes in my x86_64 Linux, versus 4 for the hash alone).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/commit/b08ae0fe65c0942dca20281d6841dc83406d8…
