why does flashdevelop compile take so long?

[jeroen w]

I just jumped into HaxeFlixel totay and got a basis game nicely working. no problems there!

the only problem is that compiling takes longer and longer. 

when I build a debug version now, it takes around 10 seconds. 

I test a lot so I got now got to the point I really wanna find a fix for this.

the only thing I can think of is that is has to do with the libraries.

I'm using:

-openFL

-flixel

-lime

-flixel addons

I tried just copying the tile folder of the addons I use, to the source folder and then removing the library.

but it didn't change much. I think it took like .5 second off.

any ideas other ideas how to compile faster?

[Gama11]

Hm... It takes longer and longer you say?

Usually, both Neko and Flash compile very fast, no problems there. Cpp targets like windows or android can take quite a while the first time, but  after that, it should be a reasonable as well. In my experience at least.

Btw, can't really blame FD for this - all it does is use the haxelib run openfl build' command.

[jeroen w]

well, it already started around 8 seconds. any example I open from the haxeflixel demo takes around this time.

how long is it supposed to take?

Op dinsdag 31 december 2013 08:58:42 UTC+1 schreef Gama11:

[Gama11]

Well, like I said, it heavily depends on the target. Compiling FlxPoingAPI in debug mode gets me:

flash - 4 seconds

windows - 26 seconds the first time, 5 seconds after that

neko - 4 seconds

[jeroen w]

Ok thanks, I'm targeting flash and with the FlxPongAPI it takes around 10 seconds for me. 

Could this just be my computer? it's a bit old. I never had building times that long though.

dont know if it says much but I build it with a verbose flag and it seems to take the longest on this part:

Running command: BUILD

-Running command: haxe/export/flash/haxe/debug.hxml

anything to do about that?

as a sidenote, I converted my haxeflixel project to as3 and it built in less than 2 seconds.

I also tried out the ActuateExample from the openFl samples and it takes around 5 second to build.

I can only guess it's this is just my laptop being slow.

Op dinsdag 31 december 2013 17:35:17 UTC+1 schreef Gama11:

[Samuel Batista]

Your build times are affected by your CPU speed, but mainly, by the speed of the drive they are on. Perhaps you could get an SSD drive? That usually speeds computers pretty significantly.

[Boyan O]

Happy New Year!

According to my experience, on Linux OpenFL can build simple projects in fraction of second.

On Windows, something slowdowns running external processes(Haxe) and etc.

On Windows with modern desktop CPU it may take few seconds. On Linux - probably less than second.

So on Windows OpenFL has to go on this chain:

"openfl build flash" -> openfl.bat converts it to "haxelib run build flash"(FD starts from this point) ->

-> haxelib executes "neko run.n build flash" -> "run.n" script generates "build.hxml" file and executes "haxe build.hxml" -> embeds assets

Also running Haxe from USB is also a bad idea, because of compilation times. 

Also Haxe compilation server may speed up compilation times there, for not C++ targets, like

Start some Haxe server:

haxe --wait 5000

openfl build flash --connect 5000

and for Windows/Mac/Linux/BlackBerry/iOS/Android:

openfl build windows

Because these targets(C++) will not work with Haxe server and may just hang.

Could you specify your CPU, if you have something like P4, then probably 8 seconds is not so bad, I got something like 4-5 seconds. And it would be good to know which OS you use.

About SSD drive - I would say go Linux, and you will have decent speed up in compilation times.

Slow HDD and/or paranoid antivirus could probably slow down compilation a lot.

вторник, 31 декабря 2013 г., 22:46:41 UTC+2 пользователь Samuel Batista написал:

[kuris]

Hi everyone, I am having the same problem, but I managed to find the reason, though I didn't find the real solution yet.

It takes me around 30 seconds to compile the project. I tested this on few computers, Windows and OSX, I also used Flash Develop and Sublime Text. All this doesnt matter much in this problem.

What matters is the number of assets you have in assets folder, this is defined by  <assets path="data"/>.

More assets there is, longer it takes to compile. I managed to reduce compile time from 35s to less than 2 seconds after I deleted all assets.

So is there any way to fix this ? Because this causes that testing bigger projects often is not possible.  

I was reading something about putting all files in single SWC, but this would make the whole routine of adding and changing assets even slower, especially compared to Adobe Professional where you can edit files inside of the visual editor.

[SruloArt]

Right now there's no good solution, as if you don't embed your assets (assets path="" embed="false") in the .swf you need to manually load them (using assets.load), which means you can't "auto-preload" them, at least not with OpenFL/Flixel. Maybe it would be a little easier using something like this: https://github.com/ProG4mr/assetsmanager.

[Ashiq A.]

One idea: limit the assets that you import. I used to keep "source"
versions (XCF, GIMP original file type) in assets, but moved those
out. You can also specify assets by type (eg. include *.png|*.jpg).
This may help.

> --
> HaxeFlixel Development Community
> See our github https://github.com/haxeflixel/ and our documentation
> http://haxeflixel.com/documentation/
> ---
> You received this message because you are subscribed to the Google Groups
> "HaxeFlixel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haxeflixel+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/haxeflixel.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haxeflixel/61c3a25e-186a-458f-80c5-24601e9ef708%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[kuris]

I did specify types, and I don't have anything in assets folders that I dont use in the swf.

Example I posted was just the simplified versions of ton of includes I had in xml, but changing this didnt affect the compile time at all.