Le 17/04/2012 18:20, Nick Treleaven a écrit :
Hi, How's it going?
Hi,
Sorry for the long delays -- and also small activity -- recently. I have/had a lot of non-Geany stuff to do and stuff, the whole story, you know.
Lex mentioned in this mail: http://lists.uvena.de/pipermail/geany/2012-April/007991.html
that (according to him) you are working to 'replace it'. Maybe he's exaggerating, but this sounds interesting. If you have time could you maybe send me a link to the IRC log, or better, explain a little about the work on the devel list?
That's true, I have a WIP on writing a new ctags management code. It is far from being ready for production, and I'm not even sure the ideas in it are really appropriate. But yes, there is a something :)
I finally committed it and pushed it so you can see it, comment, blame, flame & more: see https://github.com/b4n/geany/tree/wip%2Fctagsmanager
A few points, as they comes to my mind:
* it is under the new ctagsmanager/ directory; * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags; * it support asynchronous parsing (though not concurrent parsing); * all types have different names than the tagmanager ones, though currently the API is almost an 1:1 mapping -- and that's maybe a huge mistake?; * there is 2 backends as of today: - a "simple" one that is simple and that doesn't waste (too much) memory, but that searches in O(n); - a "multi-cache" one that, as its name suggests, maintains multiple caches (sorted tags arrays). it uses a little more memory and is slower on insertion since it maintains several sorted lists, but a search on an already existing cache is very fast.
In practice I haven't yet tested anything big enough to see any difference in performances between these two backends, and that's something that probably isn't worth bothering about for now.
* this "backend" abstraction might be really overkill, and maybe we could do better without it?; * tags (and most types) are reference-counted (so they aren't necessarily duplicated, e.g. in the multicache backend); * tag matching/finding is done using ctm_data_backend_find() (or a convenience wrapper), which takes 2 functions for performing the search: - a sort function, used to, heh, sort the tags to search and/or the resulting list (the "simple" backend should use it to sort the result; and the "multi-cache" backend uses it to sort the caches) - a match function, use to check whether a tag should be included in the results. Like the sort function it returns a strcmp()-like value, with the only difference that it probably returns 0 for more tags.
It is somewhat similar to what tagmanager did, but it's more flexible -- and maybe complex, though many sort/match functions would already be provided.
* no pruning is done yet, so there is duplicate in the results; * there is an (almost) working scope completeion implementation; * ... I don't see anything to add, so I'll stop here :)
All this isn't of course written in stone: if we already redo a lot of things, let's get something nice -- though IMO we'll always be better than with tagmanager, since each time I wanted to touch it it took me hours, and sometimes I even haven't been able to fix the problem (thinking of e.g. scope completion...).
Also, later in the thread he says that performance problems with resorting global and workspace tags cannot be fixed with the design of tagmanager. I've been working yesterday on improving this significantly by merging the new tags each time instead of resorting *all* the tags. I hope to commit this in the next few days.
Cool! I haven't done any profiling on either tagmanager or may new attempt, so I can't tell what's actually slow, but any improvement is good to have :)
Regards, Colomban