Hi
Kaloyan,
I agree, that a list of 440k instances requires some significant amount of memory.
What happens there is scanning the whole project to collect all the files, then select source modules by calling DLTKCore.create() on each file. Probably this code is also involved in causing Full GC, high memory usage is not necessary a problem, but this needs to be profiled.
Returning a list of the changed resources could be quite convenient, e.g. in the DLTK codebase it is used to clear problem markers on them - to handle cases like resource was source module before, but then was removed/excluded from buildpath, this happens in org.eclipse.dltk.internal.core.builder.StandardScriptBuilder.build(IBuildChange, IBuildState, IProgressMonitor).
Also, this method can be used by DLTK adopters to process some associated resources, etc.
Overall, an interesting case, I don't think I had ever seen so many files in a project. Honestly, I would recommend refactoring that file structure, and at the same time I don't mind improving DLTK to handle it better.
Regards,
Alex