Venting about slow macros :(

[Jeff Ward]

I'm only here to complain. It's therapeutic. Please ignore and carry on... unless you know a solution. :)

[David Elahee]

<3

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

David Elahee

[Tarwin Stroh-Spijer]

Which runtime are you using? I can imagine that the macro is slower because it's running in Neko? I'm really certain here but an idea ...

Tarwin Stroh-Spijer
_______________________

phone: +1 650 842 0920

Developer at Fanplayr Inc. (Palo Alto)

Original at Touch My Pixel (touchmypixel.com)
_______________________

[Juraj Kirchheim]

Nicolas worked on using HashLink to run macros a couple of months back, but lately I've seen no progress in that direction.

In the meantime, your best bet is trying to get your macros to play nice with the compiler server.

Best,

Juraj

[Mark Knol]

Can you share benchmark/tests/project, help spotting what exactly isnt fast?
Just saying something is slow is not helpful. Unless you think it is.

[Marcelo de Moraes Serpa]

Well, the fact is that code runs much slower in the macro context, you can see his benchmarks in the screenshots.

Nicholas suggested using the compiler server, but not sure if it's feasible for Jeff, I don't know how his project is structured.

On Thu, Apr 13, 2017 at 2:56 PM, Mark Knol <mark...@gmail.com> wrote:

Can you share benchmark/tests/project, help spotting what exactly isnt fast?
Just saying something is slow is not helpful. Unless you think it is.

[Marcelo de Moraes Serpa]

Can you even switch macro runtimes? 

[Jeff Ward]

Hi Tarwin / Mark,

The above test is the NekoVM at runtime vs the internal macro interpreter. Exact same code, and string manipulation is a fairly common macro use case. The macro interpreter is 100x slower.

I had assumed the internal interpreter was some version of Neko (maybe it is, because it matches #if neko conditions). But Nicolas indicated it is "not NekoVM". It's a fully dynamic interpreter built into the compiler, necessary because it shares memory with the compiler. I might expect a 2-10x slowdown for this, but 100x seems a bit painful.

FYI, on Twitter Dan said that Simon is looking at macro interpreter speed.

WRT using Haxe in server mode, a while back I found it didn't speed up my project, and recently there are errors reported in the second build iteration that weren't reported in the first build iteration. Apparently my macros don't play nice with the compilation server.

Best,

-Jeff

[Philippe Elsass]

Yes it would be good to know the anti-patterns for compiler server and macros. But if we can identify severe bottlenecks like these String manipulations it may be possible to solve them in priority.

Philippe 

--

[Jeff Ward]

Another data point... While the above string manipulation is a separate issue, the modular-js generator is a dog, almost tripling our build time from 2.3s to 6.3s (as determined by addiong/removing):

--macro modular.js.JsGenerator.use()

The --times -D macro-times output indicates:

macro                                 |   5.290 |  83 |   561 | 

  execution                           |   0.750 |  12 |   514 | 

    ...

  finalize                            |   0.030 |   0 |    15 | 

  flush                               |   0.070 |   1 |    15 | 

  jsGenerator                         |   4.400 |  69 |     1 |

  ... 

Hmm, I wonder if a trivial JS generator would improve things, or if any jsGenerator has this problem. I wonder if, again, it's String manipulation that's really the problem with a JS generator.

Best,

-Jeff

[Jeff Ward]

Ah, interesting, --times shows that haxe.macro.ExampleJSGenerator shows 2.0s in the jsGenerator (compared to modular-js taking 4.8s.)

So it looks like I could try to optimize modular-js, but there's a limit to how good it can get if the example js generator is still 2.0s. I wonder if js generators are impacted by the String slowness in general.

Both generators are using a StringBuf, so I could test its performance in the macro interpreter as well.

Well, at least --times -D macro-times seems to provide the tools necessary to investigate.

[Philippe Elsass]

Jeff, it would be interesting to compare with Haxe modular processing which is done using nodejs. 

--

[Jeff Ward]

Woo hoo, new eval target to the rescue! Way to go, Simon and team!

The latest nightly build with eval enabled macros increase the speed of my String.split testcase to be on par with the Neko runtime, and improvement of 100X.

[Jeff Ward]

BTW, I'm running into a couple issues with my large project, so I can't comment on the js generator improvement yet.

[Jeff Ward]

FYI, issues with large project were resolved, and this info may be useful to others -- I had overridden a couple standard library files into our project for various reasons, and those local files were missing #if eval sections (usually tacked on with the #if neko sections.)

The eval macro target seems to have sped up our project by about 3 seconds (roughly 50% savings), most of it coming out of JS generator. -D eval-times shows that JS generator still uses almost half the compile time total, so maybe there're some optimizations I could look at there.

Anyway, fantastic! This makes macros a much more attractive solution in general.

Best,

-Jeff