[Github-comments] [geany/geany] Highlight fix 2 (#1039)

Jiří Techet notifications at xxxxx
Tue May 24 13:10:05 UTC 2016


> @codebrainz is the string really that big? Compared to the scintilla source buffer it came from, with its style info and line info and its map containing the names from the previous string. Also there is tagmangler and the symbols pane GTK treeview containing the same info in greatly expanded form. The string will be considerably smaller than all of the preceeding.

I'm not @codebrainz but I have an answer :-). The string contains typenames from all open files or, when using ProjectOrganizer, the complete project (compared to the tree view which contains it for a single file only). If I remember correctly, it's about 1MB string for the Linux kernel sources.

The fact is that this string is passed to Scintilla anyway so it already consumes 1MB per open file and I guess having it stored once more and taking up 2MB per open file wouldn't be such a disaster so we could store it too if this is the preferred variant - I don't care much.

> @techee, np, just asking, since the hash time is incurred each time the parser runs, not just when there is a change. This patch is still working fine for me, though on files of a sane size :)

Yes, but we already do this every time the parsing happens:

https://github.com/geany/geany/blob/master/src/symbols.c#L200

i.e. creating the huge string by concatenating the typename array, comparing values and removing duplicates (and when getting the tag names, we have to dereference pointers so this won't be cached easily by the processor). My guess is doing the hash is much cheaper than the above so if we wanted to speed up this part, we'd first have eliminate the concatenation.

---
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/1039#issuecomment-221263214
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160524/88edf19f/attachment.html>


More information about the Github-comments mailing list