mirror of
https://github.com/eclipse-cdt/cdt
synced 2025-04-21 21:52:10 +02:00
9e7b5beaa9
Cache results of various path resolution algorithms. Resolving paths is particularly slow while creating entries, see AbstractLanguageSettingsOutputScanner.createResolvedPathEntry. There are three main callees within that method that this patch addresses with a caching approach: * findContainerForLocationURI: First, this finds containers for a given URI in the workspace using Eclipse resources API. Then a single container is selected based on a preferred project. This can done repeatedly for include paths, which are often similar for source files in a given project or source folder. This first step is the expensive one and it only depends on one argument (the URI) and a simple IResource[] return type, so the cache here is done for this operation. Then the post-filtering is kept as is. * findFileForLocationURI: Similar to the container case but for files. A typical projet has much less file paths than folder paths in its options. One more common option using file paths is -include. The same approach is applied here as the previous point because there are performance gains but they are smaller if you consider typical projet setup. * findBestFitInWorkspace: When a path cannot be found, this makes an attempt to find the parsed path relative to every folder of the workspace, by starting first with the preferred project, then its referenced projects and then the rest. Caching the result of findBestFitInWorkspace itself is too cumbersome because the result depends on 3 variables (currentProject, currentCfgDescription and parsedName) which would make a complex cache key. Instead, caching the result of findPathInFolder at the project level is sufficient, with little to no performance difference. In all three cases, the class LRUCache is used in order to limit memory consumption of the cache. A limit of 100 elements for each cache was chosen based on experimentation with a few projects like LLVM and projets several times bigger. A limit higher than necessary for small projects does not incur a noticeable overhead for small projects and a limit too small for very large projects merely diminishes the performance gains. Using LLVM code base as a test, the time to parse options for all files: Before: 68395ms, after: 5599ms Change-Id: Ib997e9373087950f9ae6d93bbb1a5f265431c6bc Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com> |
||
|---|---|---|
| .. | ||
| org.eclipse.cdt.autotools-feature | ||
| org.eclipse.cdt.autotools.core | ||
| org.eclipse.cdt.autotools.docs | ||
| org.eclipse.cdt.autotools.tests | ||
| org.eclipse.cdt.autotools.ui | ||
| org.eclipse.cdt.autotools.ui.tests | ||
| org.eclipse.cdt.build.gcc.core | ||
| org.eclipse.cdt.build.gcc.ui | ||
| org.eclipse.cdt.cmake-feature | ||
| org.eclipse.cdt.cmake.core | ||
| org.eclipse.cdt.cmake.ui | ||
| org.eclipse.cdt.cmake.ui.tests | ||
| org.eclipse.cdt.core.autotools-feature | ||
| org.eclipse.cdt.core.autotools.core | ||
| org.eclipse.cdt.core.autotools.ui | ||
| org.eclipse.cdt.gnu.build-feature | ||
| org.eclipse.cdt.make.core | ||
| org.eclipse.cdt.make.core.tests | ||
| org.eclipse.cdt.make.ui | ||
| org.eclipse.cdt.make.ui.tests | ||
| org.eclipse.cdt.managedbuilder.core | ||
| org.eclipse.cdt.managedbuilder.core.tests | ||
| org.eclipse.cdt.managedbuilder.gnu.ui | ||
| org.eclipse.cdt.managedbuilder.ui | ||
| org.eclipse.cdt.managedbuilder.ui.tests | ||
| org.eclipse.cdt.meson-feature | ||
| org.eclipse.cdt.meson.core | ||
| org.eclipse.cdt.meson.docs | ||
| org.eclipse.cdt.meson.ui | ||
| org.eclipse.cdt.meson.ui.editor | ||
| org.eclipse.cdt.meson.ui.tests | ||
| pom.xml | ||