<p>I'm hitting some performance ceilings in JavaScript for a small project of mine and I'm taking the opportunity to give go a try.</p>
<p>Do you think this code (not mine, but it is at the heart of my current issue), translated to go, would be a lot faster? </p>
<p><a href="https://pastebin.com/YbhqZuf7" rel="nofollow">Cartesian product of multiple arrays of objects</a></p>
<p>If so, do you have any tips for a first time go explorer looking for performance?.</p>
<hr/>**评论：**<br/><br/>amir20: <pre><p>My hunch is that it would make a difference. Nodejs is great at io but not so good at high cpu calculations. Go will certainly be better. Also, try pynum width python. All of the vector calculations are written in C. You should write all three and measure performance. That’s the best way to be sure. It really comes down to the implementation, so I really recommend finding a language with good vector library. </p></pre>inyourfaceplate: <pre><p>Thanks! I'll take a look at NumPy too!</p></pre>ConfuciusBateman: <pre><p>What makes Node good at IO in comparison to Go or other languages? I've never really heard that said about Node so I'd be interested to learn about it.</p></pre>soapysops: <pre><p>I don't think they meant to say that Node.js is better than Go at IO. They are implemented in the exact same way (ie. they wait on lots of sockets at once in a single thread instead of blocking in many threads), but Go can do a lot more because it isn't forced to run only one thread of business logic at a time.</p>
<p>Most languages can be just as efficient IO wise if they use the same model, but most do not have it built in to their standard library. One of the selling points of Go is it's all done for you, automatically. Though this does mean that if you were to write all the code to do the IO for your program yourself, you could be more efficient.</p></pre>amir20: <pre><p>I recommend this <a href="https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go" rel="nofollow">https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go</a> pretty much sums up everything </p></pre>shark1337: <pre><p>I second numpy. It's blazing fast and it's based on c&fortran code with a very nice syntax. It would outperform even go.</p></pre>inyourfaceplate: <pre><p>I'll have to try that after I finish the go implementation!</p></pre>k0t0n0: <pre><p><code>curr.slice()</code></p>
<p>In the loop, do you really need a copy? (no you don't need to call slice inside a loop)</p></pre>inyourfaceplate: <pre><p>Good point! My code (which currently sits around result.push(copy)) could be altered to operate on a portion of an array, or multiple array pieces rather than a tailor fit array. I'll give that a shot!</p></pre>arthurwhit3: <pre><p>The <a href="https://rosettacode.org/wiki/Cartesian_product_of_two_or_more_lists#Go" rel="nofollow">Rosetta Code - Extra credit 1</a> implementation with Go 1.10.1 vs. yours with Node 9.11.1:</p>
<pre><code>./cartprod 2,16s user 0,20s system 118% cpu 1,992 total
node cartprod.js 16,39s user 0,62s system 102% cpu 16,612 total
</code></pre>
<p>Go is 8 times faster.<br/>
If you need to handle arrays/slices of mixed types, the difference will certainly decrease but at the end, it's still a win.</p></pre>inyourfaceplate: <pre><p>This is a great start, thank you!</p></pre>jerf: <pre><p>For Go, one of the things you have the chance to do is optimize farther than even the V8 engine can safely do, because you have some non-trivial control over allocations. See <a href="https://play.golang.org/p/4Myz0fqWhIf" rel="nofollow">this example</a>, for instance, if you don't need a manifested list of the cartesian product but just need to examine each element. That is going to be very fast because it should inline (though I didn't check), does nearly the minimum possible work (not quite, but close), and by being so small and not using any memory should run entirely in L1 and still leave plenty of room for an algorithm of your own.</p>
<p>JS can't quite pull that all off.</p></pre>inyourfaceplate: <pre><p>Holy cow, that IS fast! I'll angle toward this impl. I'm currently (as other work permits) still building out the structs for the data I'll be iterating over. Should have a v1 tonight.</p>
<p>Go syntax is more different than I expected but not too painful!</p></pre>inyourfaceplate: <pre><p>@jerf In the example you linked, I'm having trouble understanding how the output of cpg.next() is getting placed into res. If you have a second, can you give me a hint or two as to what is going on there?</p>
<p>Thanks!!</p></pre>jerf: <pre><p>A slice is a pointer to an underlying array, and a start and end index. When the slice is passed to the cpg, the slice is copied, so those three values are copied, but the underlying array is not copied. So the cpg code is writing into a shared memory buffer, which is why that then doesn't have to be passed back to the iterating printing code.</p>
<p>This is what I mean by doing the minimal work. It doesn't manifest anything other than just the current value, over and over again into the same memory location. If you want to keep it, you'd have to copy it explicitly.</p></pre>pobbly: <pre><p>Go will certainly be faster with the same algo, if you want to stay in js, see if using typed arrays gives you a speedup.</p></pre>toggafneknurd: <pre><p>This code can be optimized a LOT. Writing slow code (copying arrays within a tight loop??) is a bad decision in any language</p></pre>lshevtsov: <pre><p>One thing that you can do with Go is implement the loops in <em>assembly</em>. </p>
<p>I once got an order of magnitude of performance out of rewriting a bottleneck loop - and was only 10 lines of assembly code.</p></pre>
