Community
Participate
Working Groups
Along with minor changes in Xtext and a patched PDE, I could evaluate the benefit of a MemoryFileSystem for the workspace in test projects. With SSDs it's not too beneficial as it seems as many of our tests are not i/o bound. For the xtend.ide.PerformanceTest the situation was slightly different. Best cases dropped from 40 secs to 23 secs for the test to finish (indexing of JDT was _sometimes_ faster than with java.io.Files). i/o was especially visible for our code for the code generator and the debug source installation: Task 'org.eclipse.xtext.builder.BuilderParticipant.build(IBuildContext, IProgressMonitor)' took 2027ms (9 measurements). Task 'DebugSourceInstallingCompilationParticipant.install' took 506ms (5 measurements). vs Task 'DebugSourceInstallingCompilationParticipant.install' took 2656ms (5 measurements). Task 'DebugSourceInstallingCompilationParticipant.install' took 591ms (5 measurements). A MemoryFileSystem may be more relevant on the build server where we don't use SSDs (AFAIK).
Scheduled just to make sure we discuss the idea of fixing and contributing smth to PDE.
In case we could really fix all the hard coded dependencies to java.io.File (see clients of IPath#getFile() for instance), we wouldn't be able to run our tests against older versions with an in-memory file system. And it would be very likely that it gets broken again as the API is leaky already. An alternative approach be to build with Java 7 and use something like https://github.com/google/jimfs
After an offline discussion we decided to postpone further progress here. I'll commit the changes in our code that are necessary to support the EFS for Xtext languages and progress with other options for now.
