I am currently working on game development. This project heavily uses Haxe to write domain logic. As project becomes bigger and bigger, the build time has increased to 10 sec. Even if build server is turned-on, it still don’t show much improvement.
Is there any way can speedup build time? (like build per package or something)
the following image shows compiler time with Haxe 3.4.7:
I wonder what’s that command timing. Is that -cmd? But then why it’s only present in the build server build?
Also it looks like macros are executed a lot and/or doing expensive work, and most of them (2088/2089) are still executed even with rebuilding with cache server, which means something is not cache-friendly. Still, merely upgrading to Haxe 4 should speed up the macro part because the new interpereter is much faster.
But yeah, actual c# generation (gencommon_filters is part of that too) and native compilation takes quite some time, I’m not sure how much can be done there :-/
First, thanks for your replay :P, and sorry for my long post Orz
the only different compile option between two build is --connect 6000, so command is just popped up with build server maybe?
Unfortunately we cannot update Haxe to 4 (for now), because most library we used are still in 3.4. I also found an issue that describe a real project with more than 20 sec build time. Consider my project only has 40,000 LoC (with 110,000 Loc in lib), it seems not a right way for building middle level project (compare to pre-built jar or dll). I think the long build time will be a bottleneck of developing any larger Haxe in the future, consider there are more and more people want to build reusable component.
I know it’s not going to be helpful but maybe you can try commenting out the yield macro and these extra libs to see how they impact on overall build times.
Think twice, the design of tink_* series library maybe right. Although tiny modules create bunch of dependency, but this design actually decrease total size of project. Maybe it is the best that Haxe library can do?
BTW just checking, but when you show build server times it is for successive builds right?
As typing time stays the same it seems that you have a typicial case of macros preventing types to be cached. Probably every class with the yield meta will be re-typed for instance.
Another suspicious thing, although it’s small, is Buddy unit tests has macro times. I think you really need to create a clean hxml without any useless libs.
yes, but I did remove some library to make build server work. Some macros are not cache-friendly, so I just disable them for more accurate measurement.
I think you are right, so I tried to remove all useless libs and tests and re-run. However, the build time becomes longer. The code I added in this morning should not be that much…
Most likely command here stands for the native compilation step, which is executed via the same means as -cmd arguments.
It’s just not tracked in --times for non-server compilation.
Interesting topic. This got me wondering if I should use the build server, so I went looking for the documentation. It took me a little while to figure out that the Completion Server page is what I wanted. Perhaps that page should be named “Compilation & Completion Server” or something better?