[Geany-devel] tagmanager changes
Colomban Wendling
lists.ban at xxxxx
Tue Apr 24 21:31:32 UTC 2012
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
More information about the Devel
mailing list