[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