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 _______________________________________________ Geany-devel mailing list [email protected] https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
