I noticed that when I look for methods with a common name in a large project, a lot of time is spent in StubIndexImpl.processElements. This wouldn't be a problem per se, but the functions holds an index lock while iterating over the possible files.
Some notes because the questions will come up:
- The reason the process is slow is not the work that is done for each element -- I can use an empty processor, but it still takes a long time (a long time being up to a second when searching for very common function names such as "get"). Because the function holds an index lock, and because apparently some other part of the UI waits for it, this makes the UI unacceptably laggy.
- I am holding a read lock when I call this function. I am happy to relinquish that lock at any time. In fact, I already do that in other places, and I have an ApplicationListener that will let me know whenever someone wants to start a write action. If that happens, I will give up my read lock and pause my own processing until the write action is over. I will then reacquire the read lock and continue. This works great, but I cannot relinquish my read lock while I am inside of processElements -- that will quickly lead to a deadlock as the write action tries to acquire an index lock (which is still held by processElements).
I would like to have (write) a function equivalent to processElement with lesser consistency guarantees which holds the lock for a much shorter period of time. I imagine this working like this:
- get the lock
- make a deep copy of the ValueContainer returned by index.getData(key) using container.foreach, and call that containerCopy
- release the lock
- apply the container.foreach loop that does the actual processing to containerCopy, but use the version of myStubProcessingHelper.processStubsInFile that ignores index inconsistencies: processStubsInFile(... skipOnErrors=true)
This should (silently) ignore inconsistencies, and may miss elements in files that have been updated after we released the lock (and before we process the file). I'd be very happy with such an approximate set of values, if it means that the UI reliably doesn't lock up.
I cannot do this in my own code because myIndices is private, and I need to call myIndices.get(indexKey).getData(key). If StubIndex(Impl) had a public or protected function computing step 2 above, a deep copy of myIndices.get(indexKey).getData(key), that would also make me happy.
Before I go down that path, is there a better way to get what I want? I'm happy to make a patch, it doesn't look hard, but I may not be aware of some subtleties relating to indexing.