Source code protection? I guess this is some form of security by obscurity when distributing to clients? If it's for in-house code, why would you limit it to the set of data covered by this framework rather than proper encryption for your whole project?
How Node.js applications will benefit from replacing V8 in JXcore
11–20 of 24 posts
Re: How Node.js applications will benefit from replacing V8 in JXcore
#12[deleted]
Re: How Node.js applications will benefit from replacing V8 in JXcore
#13How exactly does JXCore manage to beat years worth of optimisation engineering by Google? I'm skeptical, especially since I can imagine an engineering tradeoff between performance and stability. Maybe V8 is slower because they fixed crash bugs caused by overoptimistic code generation. What assurances does anyone have that their slower but working V8 code won't be fast and broken in a new engine?
Performance is measurable not in years.
Re: How Node.js applications will benefit from replacing V8 in JXcore
#14What are you doing computing heavy stuff in JS for?
Standard JS community brain-damage. Come for the hype, stay for the sunk cost of learning all those awful quirks and flaws.
Re: How Node.js applications will benefit from replacing V8 in JXcore
#15Nothing to see here. Author uses Octane benchmark where bigger is better, so v8 ~26 beats the "experimental engine".
Q: What do the scores mean?
A: In a nutshell: bigger is better. Octane measures the time a test takes to complete and then assigns a score that is inversely proportional to the run time (historically, Firefox 2 produced a score of 100 on an old benchmark rig the V8 team used).
Re: How Node.js applications will benefit from replacing V8 in JXcore
#16How exactly does JXCore manage to beat years worth of optimisation engineering by Google? I'm skeptical, especially since I can imagine an engineering tradeoff between performance and stability. Maybe V8 is slower because they fixed crash bugs caused by overoptimistic code generation. What assurances does anyone have that their slower but working V8 code won't be fast and broken in a new engine?
It doesn't. The benchmark clearly shows that V8 is faster than JXCore, because lower scores are worse .
Looking at the linked benchmark file appears to bear out this claim:
https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core...
It appears that the reported numbers for benchmark X are _the # of times that X can be run before one second elapses_, so parent comment is correct and the premise of the blogpost (that the new node.js version with V8 has worse performance than the earlier version / the private fork has better performance than the new version and slightly worse performance than the old) is contradicted by the evidence presented.
Not a good way to look competent, posting something like this. Countdown until edit or takedown...
Re: How Node.js applications will benefit from replacing V8 in JXcore
#17What are you doing computing heavy stuff in JS for?
Looks like http://nubisa.com/ is interested in native (read: mobile, desktop) app development in JS.
Re: How Node.js applications will benefit from replacing V8 in JXcore
#18Seems double-silly. First there's the whole "smaller is better... I mean, whoops!"-ness of the blogpost. Second is the general choice of benchmark: JXcore is supposed to be a multithreaded JS engine, so it seems like you'd want to benchmark its multithreaded performance against V8's single thread perf. on some workload that can take advantage of multiple threads.
Re: How Node.js applications will benefit from replacing V8 in JXcore
#19Maybe JXcore will come with a new LLVM Javascript Frontend?
Looking forward to it.
Re: How Node.js applications will benefit from replacing V8 in JXcore
#20Nothing to see here. Author uses Octane benchmark where bigger is better, so v8 ~26 beats the "experimental engine". Q: What do the scores mean? A: In a nutshell: bigger is better. Octane measures the time a test takes to complete and then assigns a score that is inversely proportional to the run time (historically, Firefox 2 produced a score of 100 on an old benchmark rig the V8 team used). https://developers.google…
Reproduced the lower node 0.11.10 performance on gentoo.
time node core_engine_benchmark.js
as author answered below comment, the performance gain/loss could be from switches hence the combination of latest v8/node
Clearly the blog posting focuses around the second item (as a biggest replacement reasoning) which is available on both new and old v8. I couldn't reproduce the same problem on i.e. spidermonkey cli but it's visible on node 0.10.26 / 0.11.13