Re: finding all Java classes in a project

(moving nbdev as the issue has nothing to do with projects)

> Although MDR is logically a cache, it is essentially a database for 
> objects and their relationships. Some people use databases for caching 
> data which are hard (but possible) to obtain.
>
> Update is necessary if the function needs to return accurate results, 
> rather than those from most-recent update, or partial results from an 
> update running in background right now.

That is just one implementation. You don't have to do it that way.

As I mentioned on this list a few months ago, trying to calculate all 
the information
about types, usages etc. and keeping them in sync is much harder (in 
terms of both
correctness and performance) than keeping some  more higher level data 
in a lightweight
cache  and calculating the other details like usages on demand as needed.

For example, my prototype for this kind of  implementation loads all the 
JDK classes in < 3
seconds and doing something like find usages (whereused) of String and 
all its methods
and fileds takes about 40 seconds and finds about 10,000 uses. On the 
other hand, our
current MDR takes several minutes (~10 minutes?) to initially load the 
sources. Obviously,
find usages is instantaneous, but I am not sure if it will scale and 
also how expensive it is to
keep these things in sync.

Sreeni.