* designing a caching strategy seems fairly easy here.
Probably doable, yes, though both harder than the approach I
described, and almost certainly slower even with cache (which needs
regular invalidation). And the first search in the session (without
cache to fall back on) will likely hurt the most.
You can very well make big parts of the database when building, for
example when byte-compiling. And you only invalidate when you change a
file.
Anyway, good luck. I just hope you don't end up with etags-like
approach where the user will need to built and rebuild the index
manually every time they want it to be fresh.
No that's not the goal. The goal is to make a proper symbolic
xref-find-references for elisp which isn't regexp based (and which takes
around 4-5 seconds here everytime, btw...
Anyway, the reason I'm reasonably confident this _can_ be done is also
because this _has_ been done, in Common Lisp implementations. That's
were xref.el comes from, ultimately. They use even more advanced stuff,
like macroexpansion, so they catch the make-foo of defstruct. Some
implementations have even more advanced stuff like proper who-calls,
who-sets, who-macroexpands. They've had it for decades! Have a look at
SLIME or Sly and plug them to SBCL or Allegro Common Lisp, for example.