[...]
I don't understand why tagmanager has to be replaced, why not just replace the parts you want to improve? Rewriting it is likely to lead to a new set of bugs and be hard to review and merge changes from master.
Hi Nick,
It is good to see someone supporting tagmanager rather than it just being trashed (by the likes of me :)
One of the problems with tagmanager is its complexity, leading to considerable wariness on the part of many of us about changing it since we don't understand what we might break.
Actually documenting the overall structure of tagmanager and how it is supposed to work would be a good thing, whats a workspace? what is it meant to represent, how are scopes represented? etc.
[...]
- 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.
Won't this be slow for adding many tags at once? How is this design better than tagmanager?
Perhaps Colomban could confirm, but my first thought is that this is for nested scopes.
How does tagmanager handle nested scopes, or how would it need to be modified to do so, considering the example (in C)
{ struct a o; struct a p; o./* struct a members */ { struct b o; o./* struct b members */ p./* struct a members */ } o./* struct a members */ p./* struct a members */ { struct c o; o./* struct c members */ p./* struct a members */ } o./* struct a members */ p./* struct a members */ }
How much needs to be changed in tagmanager so that the right autocompletes can be provided at each comment? (assuming c.c is taught to parse local variables of course)
And of course the same question for Colomban.
Given my global tags merge change (see below), I think tagmanager needs some changes to avoid sorting the workspace tags array each time tags are updated, but this is certainly doable.
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?;
I don't see why having two is better. The memory overhead for a pointer array is not much vs. the size of the tag structures. Fast searching is important.
It is but is it flexible enough to be expanded to nested scopes.
- tags (and most types) are reference-counted (so they aren't
necessarily duplicated, e.g. in the multicache backend);
I don't really understand src/symbols.c since the real-time parsing change, so don't really understand why this is needed.
Blame C++ and overloaded names I think.
[...]
I don't really see what the problem understanding it is. I thought scope completion was just tm_workspace_find_scoped and related functions, not some tagmanager-wide problem.
I think the fact that this isn't clear is the problem :)
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 :)
I finished the global tags merging change: https://github.com/geany/geany/commit/712cdd6aa0005f65bd77b15c34cd2906786462...
IMO this should make loading global tags fast enough, even for heavy use, as the whole array is now only traversed once.
Excellent, good one Nick.
Cheers Lex