Compiler Performances

[ncannasse]

I did some investigation of compiler performances, using the following benchmark:

1) compiling the whole Evoland 2 source code into a compiler cache 2) recompile several times without touching anything 3) touch a single file, and see how much times it takes to recompile the dependencies

What I think is most important for general workflow is (3). It is nice to have (1) as well, (2) can be seen as some minimal we cannot really go under (time for generator mostly).

Using an old Haxe development (compiled on May 19) which we used in the final phase of development for Evo2

With -dce no: 1) 20.0s 2) 2.2s 3) 6.3s

With -dce full: 1) 21.5s 2) 2.97s 3) 6.9s

Using Haxe development (current GIT);

With -dce no: 1) 21.7s 2) 2.25s 3) 8.17s

With -dce full: 1) 22.4s 2) 3.5s 3) 8.7s

As you notice, the most important measurement has been slowed down by ~30% for a reason still unknown to me.

Instead of doing of fixing what could be actually several issues I suggest we should do the following:

• put in place some way to track performance regressions, for each commit, with a nice graphics output and access to each commit "performance index". And replay the commit history since 3.0 (if we can go that far depending on the code samples we compile). I suggest @andyli could take care of that.
• perform an overall analysis of the current status of compilation times (pre generation) using OCaml linux gprof and investigate room for "easy" performances improvements, I suggest @Simn could look at it.

We need also to build a few stable code bases to test against. I have a few libraries which makes quite large code and that I maintain that I propose to be included in this:

• format
• hscript
• heaps (also covers some macros benchmarks for shader compilation)

If you know other significant code base that we can test, please report it there. The more we have the better our analysis will be.

[Simn]

I did some profiling but all I really found out is that we spend most of the time in the GC and doing PMap/Map lookups.

The new analyzer transformations certainly increases compile-time by a bit, but it shouldn't have that much of an impact. I can probably save some time if -D analyzer is not active because in that case we don't need any tvar information.

[ncannasse]

For the record, I added extLib/SMap which is a specialized PMap with String keys. It saves the extra record for holding the comparison function and comparisons are no longer polymorphic.

I tried to replace all fields table (class, enum, anon), took some time but I managed to test using Evoland2, without any noticable speed results. I also tried to store only ints into the SMap, by using a hash function + unique id per string, it was more costly than using PMap.

I will have to setup a Linux to good profiling results and analyze them

[Simn]

I still don't really understand how that map is supposed to be faster than module StringMap = Map.Make(struct type t = string let compare = String.compare end).

[ncannasse]

@Simn ah, that should be pretty much the same implementation, only it allows us to modify things if we wish

[fponticelli]

I think thx.core (and possibly other thx libs) would make nice candidates. They are all cross-platform and in the past they provided a lot of feedback on target specific issues.

On Sun, Apr 3, 2016 at 9:52 AM, Nicolas Cannasse notifications@github.com wrote:

@Simn https://github.com/Simn ah, that should be pretty much the same implementation, only it allows us to modify things if we wish

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/haxe/issues/4826#issuecomment-205002250

[Simn]

For the DCE issue see #5716.

[Simn]

The DCE issue has been fixed.