COMMUNITY

How to speedup build time?

build-server
#1

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:

  • normal build
    times

  • with build server
    times

1 Like
(Dan Korostelev) #2

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 :-/

(Jens Fischer) #3

-D macro-times is helpful to give a more detailed breakdown of which macros are taking the most time (used in addition to --times).

#4

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.

check haxelib library

-lib hxcpp:3.4.188
-lib hxcs:3.4.0
-lib hxjava:3.2.0
-lib checkstyle:2.4.2
-lib dox:git:https://github.com/HaxeFoundation/dox.git#master

for hxDaedalus

-D format

for haxe-yield

–macro yield.parser.Parser.auto()

include build path

-cp src
-cp lib

enable extra optimization

-D analyzer-optimize

include all module

–macro include(‘cave’)
–macro include(‘dm’)
–macro include(‘nekosith’, true, [‘nekosith.incubator’])
–macro include(‘umbraseal’)

include test path

-cp test

config utest

-D hidesuccess
-D showheader

config buddy

-D buddy-ignore-passing-specs

config test main

-main Main

prevent purge generated code

-dce no

display build profile

–times
-D macro-times

cs build command

-cs bin
-D no-root

–connect 6000

(Philippe) #5

Why do you include hxcpp, hxjava and dox libs?

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.

(Jens Fischer) #6

Including the checkstyle lib is quite unusual as well.

#7

It is for other standalone project (still working on splitting hxml). BTW, they seems don’t affect build time at all.

(Jens Fischer) #8

That seems expected, since it’s unnecessary to include them via -lib. :slight_smile:

1 Like
(Philippe) #9

It’s worth checking because some libs define extra compiler arguments which can contain macros :+1:

1 Like
#10

It seems no change :stuck_out_tongue:

#11

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?

(Philippe) #12

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.

#13

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…

for hxDaedalus

-D format

for haxe-yield

–macro yield.parser.Parser.auto()

include build path

-cp src
-cp lib

enable extra optimization

-D analyzer-optimize

include all module

–macro include(‘cave’)
–macro include(‘dm’)
–macro include(‘umbraseal’)

config main

-main Main

prevent purge generated code

-dce no

display build profile

–times
-D macro-times

cs build command

-cs bin
-D no-root

(Philippe) #14

Well you have a lot of macros, but I think we need to figure this huge command times.

1 Like
(Aleksandr Kuzmenko) #15

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.

2 Likes
#16

Not very relevant thought: if Haxe can pre-built module, does it become less painful?

(Philippe) #17

All things considered, 10s isn’t much :slight_smile: I have non-Haxe JS projects taking minutes (!) To compile.

What would be problematic is if this would impact seriously your coding comfort by preventing code completion to be fast.

(Allan Dowdeswell) #18

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?

(Jens Fischer) #19

Fyi, if you’re using VSCode, you might already be using it without realizing (tasks created by the Haxe extension add --connect by default). :slight_smile:

(Allan Dowdeswell) #20

Indeed I am, thank you!