Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prepack helps make JavaScript code more efficient

prepack.io

Post reply on HN
Print view View original

111–120 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#111

Post by andreyf »

abritinthebay wrote: post #101
andreyf wrote: post #96

Earlier quoted context omitted.

False: an implicit patent grant means that by open sourcing a piece of software you imply that people can, you know, use it.

And the weakness, legally speaking, of implicit patent grants was one major reason why GPL moved from v2 to v3. Explicit is much much safer for users of software, legally speaking, because implicit grants have to be settled in court . If you really want to go to court over it, and can afford it, then you may be right. Want to test that against Facebook? They reasoned (quite rightly) that it would be silly to suggest…

What would their case be? "Yes, we gave away the software and documented it and paid designers to design it all pretty and spent marketing effort promoting it but nobody is allowed to use it because it's patented technology"?

Has any court ever ruled that a permissive license like BSD does not include a patent grant when it says "use in source and binary forms, with or without modification, are permitted"? Because that seems flat-out silly.

Re: Prepack helps make JavaScript code more efficient

#112

Post by evv »

dschnurr wrote: post #77

This is cool–it's worth mentioning that you might be trading runtime performance for bundle size though, here's a contrived example to demonstrate: http://i.imgur.com/38CR3Ws.jpg

Keep in mind that everything is gzipped nowadays, so it may not make a big difference in network usage. Although it is still likely to cause some memory overhead

Re: Prepack helps make JavaScript code more efficient

#113

Post by GordonS »

iamleppert wrote: post #47

Not a comment about the tool, which looks cool and well done. It's sad that there are developers and projects who write the type of code that causes these sorts of performance trade offs. I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it. You're just shooting yourself in the foot in the long run. I think static analysis performance optimization tools are great but a certain…

> It's sad that there are developers and projects who write the type of code that causes these sorts of performance trade offs. I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it. You're just shooting yourself in the foot in the long run.

I respectfully disagree :)

I stopped writing excessively terse, 'overly clever', borderline 'minified' code a long time ago when I realised it wasn't worth it - it isn't readable, and it certainly isn't maintainable by my future self, let alone others. Maintainability is generally more important than saving a few cycles. Abstraction does not necessarily === "shitty code" - abstractions help us to build a mental model and reason about what the code is doing.

Having said that, I certainly see where you're coming from - abstraction can be overused, taken to the nth degree such that it's almost impossible to work out how anything actually works, and I do rather loathe such excessively heavy frameworks. But Prepack can help optimise the good frameworks that use just enough abstraction.

On the face of it, Prepack gives us the best of both worlds - developers can write maintainable code, and Prepack can optimise it a bit for us. Others here have menioned it too, but I see it as akin to the same sort of optimisations that compilers generally do.

Re: Prepack helps make JavaScript code more efficient

#114

Post by chime »

This has promise but still needs more work. I added one line to their 9 line demo ( https://prepack.io/repl.html ) and it ballooned to 1400+ lines of junk:

    (function() {
      function fib(x) {
        y = Date.now(); // the useless line I added
        return x  42) x = fib(10);
      global.result = x;
    })();
I understand Date might not be acceptable for inner loops but a lot of my code that deals with scheduling would benefit significantly if I could precompute some of the core values/arrays using a tool like prepack.

Re: Prepack helps make JavaScript code more efficient

#116

Post by hinkley »

ezekg wrote: post #100
newtonapple wrote: post #60

Earlier quoted context omitted.

What will happen if you have bug in your function? Take the fibonacci function for example, what if you have a bug and created an infinite loop? Will Prepack terminate?

I was thinking something similar: how does Prepack determine that a function can't be optimized or hits an infinite loop? Seems like the good ol Halting Problem[0]. [0]: https://en.wikipedia.org/wiki/Halting_problem

The Halting Problem is a bit like Information Theory.

Information Theory, and the Pigeon Hole Principle in specific, says there is no algorithm that can compress all data. That doesn't mean that compression is a fruitless endeavor and we should never have written a compression library.

It means that you have to figure out if your input falls into a subset of data where the outcome of the effort is both tractable and useful. You compress text and structured data, you don't compress noisy data or already compressed data, because it's usually worse than doing nothing.

Similar thing with code analysis. If there is back branching or asynchronous code, you are probably going to hit the Halting Problem, so don't even try. But if the code is linear, then precomputing the output is tractable and useful.

You could also simply apply a budget. If an attempt to unroll a block of code exceeds a certain number of clock cycles or branch operations, you should give up and look at the next most likely scenario. The analysis you're doing might reliably halt in an hour, but who wants to wait that long? Especially when it's one of many such evaluations you'll have to do per build or per day? Just give up and keep moving.

Re: Prepack helps make JavaScript code more efficient

#117

Post by SamBam »

iamleppert wrote: post #47

Not a comment about the tool, which looks cool and well done. It's sad that there are developers and projects who write the type of code that causes these sorts of performance trade offs. I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it. You're just shooting yourself in the foot in the long run. I think static analysis performance optimization tools are great but a certain…

> I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it

I'm not sure what you mean by "fancy code." I feel like it's the opposite. We often try to write code that is readable and maintainable, and has as few as possible "fancy" magical constants littered throughout it, but I'm happy if a compiler wants to optimize it.

If I have to specify some variable, e.g. `frameRate = 60` and then I have a whole bunch of other variables throughout the code that depend on it, then I'm going to reference framerate everywhere: `framePeriod = 1/frameRate; frameBufferSize = frameRate * 100` or whatever. This way if we change our specs, I have a single number to change, instead of dozens of numbers that all depends on each other.

Similarly, if I'm calculating the volume of a sphere, you bet I'm going to put `v = 4/3 * Math.PI * Math.pow(r, 3)`, because it's a meaningful statement that everyone will understand, without trying to get "fancy" by optimizing it.

But should a compiler optimize it? Heck yeah.

Re: Prepack helps make JavaScript code more efficient

#118

Post by jessaustin »

SamBam wrote: post #110
djsumdog wrote: post #55

Earlier quoted context omitted.

The examples seem more typical of Coffeescript output.

You've mentioned that a couple times, but I'm really not seeing it. What to you looks like coffeescript there?

"Coffeescript output" is javascript so it doesn't look much like coffeescript. Presumably GP doesn't like the specific javascript idioms to which coffeescript transpiles.

Re: Prepack helps make JavaScript code more efficient

#119

Post by slavik81 »

abritinthebay wrote: post #101
andreyf wrote: post #96

Earlier quoted context omitted.

False: an implicit patent grant means that by open sourcing a piece of software you imply that people can, you know, use it.

And the weakness, legally speaking, of implicit patent grants was one major reason why GPL moved from v2 to v3. Explicit is much much safer for users of software, legally speaking, because implicit grants have to be settled in court . If you really want to go to court over it, and can afford it, then you may be right. Want to test that against Facebook? They reasoned (quite rightly) that it would be silly to suggest…

I can read and understand the MIT or BSD licenses. That is an extremely valuable property of a contract to me. Both clearly state that I may modify and distribute the software.

Adding a huge pile of details about what exactly that means makes me rather nervous. I am not a lawyer, and I worry that somewhere in that huge pile of explicitness that there are consequences that I don't anticipate, and that don't match up with the broad simple language those explicit details replaced.

Re: Prepack helps make JavaScript code more efficient

#120

Post by vikeri »

timruffles wrote: post #39
vikeri wrote: post #13

I was under the impression that V8 and the like are so optimized that this would give marginal gains. Would love to be wrong though. Do you have any performance benchmarks?

Reducing this initial work would really help startup time - especially on mobile. Consider that v8 etc are really fast only after the JIT kicks in after seeing repeated work: for time-to-first-significant-paint that's too late.

I see, that makes total sense and I've run into that exact problem in my React Native app. Global defines take seconds to be defined initially since they need to execute functions. Would still be interested in benchmarks tough
Post reply on HN