--enable-source-map is incredibly slow

[gfx]

$ time jsx --output a.js --enable-source-map src/jsx-node-front.jsx 

real    12m50.548s
user    12m9.954s
sys 0m44.009s

No way! It's impossible to use.

We'd better port the source-map module to JSX and improve its internals.

[joelgwebber]

Glad to know it's not just an error on my part -- I'm seeing 3-5 minute source-map generation times as well.

At a glance, this leads me to believe that some aspect of the way they're computed has gone wildly superlinear in complexity -- generation of source-maps should be linear time.

I haven't looked into the code yet, but if no one on the team is currently looking at it, I'd be happy to dig in and fix it. If someone's already working on it, though, I'll just wait.

[gfx]

Thank you for your proposal!

This is not a high-priority issue, because no one in our team uses source-map for now.
I think it might be a limitation of mozilla/source-map.

[joelgwebber]

I understand; thanks for following up. I may have a bit of free time in the next couple of weeks to look at this.

We're particularly concerned with being able to debug live production systems, which means we need to be able to debug the output of the Closure Compiler. We're currently doing so by optionally serving the raw JSX output, which isn't that difficult to debug. But I'm eventually going to implement a mechanism for compositing source-maps, such that we can generate a single source-map that maps all the way from closure-optimized output to jsx source. I was going to do this in Java, just because Closure already contains an efficient library for manipulating source maps. But if we end up with an efficient jsx source-map library, it might be simpler to just use that throughout.

This does bring up one question -- do you have any plans to roll closure-style optimizations directly into JSX, or will you likely continue emitting Closure-annotated output? I'm thinking about this primarily from the perspective of how best to compose source-maps, and whether that should be a separate, external process.

[kazuho]

do you have any plans to roll closure-style optimizations directly into JSX, or will you likely continue emitting Closure-annotated output?

Actually, our understanding is that the built-in optimizer of JSX (which is turned on either by explicitly using the "--optimize" option or implicitly using the "--release" option) is already superior to that of Closure Compiler in terms of execution speed optimization.

I am currently working on output minification (I have now filed it as issue #143) which is the other reason for applying Closure Compiler to the output of JSX. Once the work is complete, we plan to stop emitting annotation comments for Closure Compiler.

[joelgwebber]

That's great to hear, thanks! It's not too surprising that JSX is already outperforming Closure-compiled output -- it have to jump through a lot of hoops to deal with all the bizarre forms of legal Javascript it has to accept, making a lot of optimizations very difficult.

The only reason we're using Closure at this point is for minification, at which it does a very good job. But this certainly increases our build complexity, so I'd love to be able to drop it. This will, of course, simplify end-to-end source-maps considerably.

[gfx]

See #160 to combine --enable-source-map and --minify.