Hi all,
I'm looking into some performance degradation when running one of my tests for several days. In particular, an ever increasing amount of properties are written, such as this one:
properties/TestProject.com.[..].cpp.projectType[..]Cpp.0.1287193101/com.[..].cpp.config.release.0.1623134955 -> com.[..].cpp.tool.cpp.linker.base.0.1951643695=rebuildState\=true\n
com.[..].cpp.config.release.0.1623134955=rebuildState\=true\n
com.[..].cpp.toolchain.release.0.692848118=rebuildState\=true\n
com.[..].cpp.tool.assembler.base.0.662171695=rebuildState\=true\n
com.[..].cpp.tool.c.compiler.base.0.373959980=rebuildState\=true\n
com.[..].cpp.tool.cpp.compiler.release.0.1668792322=rebuildState\=true\n
(we have some custom names here, I doubt they are relevant)
The test will create a CDT-based project, do some stuff with it and then delete it. After repeating the test for some days, I see upward of 20k such properties being written when Eclipse preferences are persisted. This causes test execution to become progressively slower.
The part from the CDT project configuration in our code which seems to be leaking is:
IManagedProject managedProject = ManagedBuildManager.createManagedProject(project, projectType);
IConfiguration config = managedProject.createConfiguration(parentAllConfig, childAllConfigId);
(we then set language providers and some other stuff on the config)
The stack trace of creating the preference is:
at org.eclipse.core.internal.preferences.EclipsePreferences.firePreferenceEvent(EclipsePreferences.java:840)
at org.eclipse.core.internal.preferences.EclipsePreferences.put(EclipsePreferences.java:865)
at org.eclipse.cdt.managedbuilder.internal.core.PropertyManager.storeString(PropertyManager.java:317)
at org.eclipse.cdt.managedbuilder.internal.core.PropertyManager.storeData(PropertyManager.java:310)
at org.eclipse.cdt.managedbuilder.internal.core.PropertyManager.setLoaddedData(PropertyManager.java:426)
at org.eclipse.cdt.managedbuilder.internal.core.PropertyManager.getData(PropertyManager.java:367)
at org.eclipse.cdt.managedbuilder.internal.core.PropertyManager.loadProperties(PropertyManager.java:191)
at org.eclipse.cdt.managedbuilder.internal.core.PropertyManager.getProperties(PropertyManager.java:129)
at org.eclipse.cdt.managedbuilder.internal.core.PropertyManager.setProperty(PropertyManager.java:113)
at org.eclipse.cdt.managedbuilder.internal.core.PropertyManager.setProperty(PropertyManager.java:444)
at org.eclipse.cdt.managedbuilder.internal.core.ToolChain.saveRebuildState(ToolChain.java:2080)
at org.eclipse.cdt.managedbuilder.internal.core.ToolChain.setRebuildState(ToolChain.java:2064)
at org.eclipse.cdt.managedbuilder.internal.core.ToolChain.<init>(ToolChain.java:237)
at org.eclipse.cdt.managedbuilder.internal.core.FolderInfo.createToolChain(FolderInfo.java:390)
at org.eclipse.cdt.managedbuilder.internal.core.FolderInfo.<init>(FolderInfo.java:195)
at org.eclipse.cdt.managedbuilder.internal.core.Configuration.copySettingsFrom(Configuration.java:700)
at org.eclipse.cdt.managedbuilder.internal.core.Configuration.<init>(Configuration.java:636)
at org.eclipse.cdt.managedbuilder.internal.core.ManagedProject.createConfiguration(ManagedProject.java:302)
(we use CDT 9.11 so the stack trace lines might not be up-to-date)
I've tried adding some code to ManagedBuildManager.doSetLoaddedInfo(), that will ask the removed info for the IManagedProject to then remove the created configurations. This doesn't seem to help.
So I have questions:
1. Is there some clean-up code that I'm supposed to call here?
2. Should I try to reproduce and open a bug? Or is there a bug report already (that I didn't find)?
Best regards and thanks,
Simeon
