It turns out that the coding in my example here was structured in just the right way to fall off a known performance cliff in the V8 JavaScript engine...
See the discussion over on bugs.chromium.org for the details. This bug is now being worked on and should be fixed in the near future.
I tried to isolate the coding that behaves in the manner described below into a single page Web app, but in doing so, the behaviour disappeared(??). However, the behaviour described below does still exist in the context of the full application.
That said, I have since optimised the fractal calculation coding and this problem is no longer an issue in the live version. Should anyone be interested, the JavaScript module that manifests this problem is still available here
I've just completed a small Web-based app to compare the performance of browser-based JavaScript with Web Assembly. This app calculates a Mandelbrot Set image, then as you move the mouse pointer over that image, the corresponding Julia Set is dynamically calculated and the calculation time is displayed.
You can switch between using JavaScript (press 'j') or WebAssembly (press 'w') to perform the calculation and compare runtimes.
Click here to see the working app
However, in writing this code, I discovered some unexpectedly strange JavaScript performance behaviour...
This problem seems to be specific to the V8 JavaScript engine used in Chrome and Brave. This problem does not appear in browsers using SpiderMonkey (Firefox) or JavaScriptCore (Safari). I have not been able to test this in a browser using the Chakra engine
All the JavaScript code for this Web app has been written as ES6 Modules
I've tried rewriting all the functions using the traditional function
syntax rather than the new ES6 arrow syntax. Unfortunately, this does not make any appreciable difference
The performance problem seems to relate to the scope within which a JavaScript function is created. In this app, I call two partial functions, each of which gives me back another function. I then pass these generated functions as arguments to another function that is called inside a nested for
loop.
Relative to the function within which it executes, it appears that a for
loop creates something resembling its own scope (not sure its a full-blown scope though). Then, passing generated functions across this scope(?) boundary is expensive.
Each partial function receives the X or Y value of the mouse pointer's position over the Mandelbrot Set image, and returns the function to be iterated when calculating the corresponding Julia set:
const makeJuliaXStepFn = mandelXCoord => (x, y) => mandelXCoord + diffOfSquares(x, y)
const makeJuliaYStepFn = mandelYCoord => (x, y) => mandelYCoord + (2 * x * y)
These functions are called within the following logic:
mousemove
eventThe current location of the mouse pointer is translated to the coordinate space of Mandelbrot set and the (X,Y) coordinates are passed to function juliaCalcJS
to calculate the corresponding Julia Set.
When creating any particular Julia Set, the above two partial functions are called to generate the functions to be iterated when creating the Julia Set
A nested for
loop then calls function juliaIter
to calculate the colour of every pixel in the Julia set. The full coding can be seen here, but the essential logic is as follows:
const juliaCalcJS =
(cvs, juliaSpace) => {
// Snip - initialise canvas and create a new image array
// Generate functions for calculating the current Julia Set
let juliaXStepFn = makeJuliaXStepFn(juliaSpace.mandelXCoord)
let juliaYStepFn = makeJuliaYStepFn(juliaSpace.mandelYCoord)
// For each pixel in the canvas...
for (let iy = 0; iy < cvs.height; ++iy) {
for (let ix = 0; ix < cvs.width; ++ix) {
// Translate pixel values to coordinate space of Julia Set
let x_coord = juliaSpace.xMin + (juliaSpace.xMax - juliaSpace.xMin) * ix / (cvs.width - 1)
let y_coord = juliaSpace.yMin + (juliaSpace.yMax - juliaSpace.yMin) * iy / (cvs.height - 1)
// Calculate colour of the current pixel
let thisColour = juliaIter(x_coord, y_coord, juliaXStepFn, juliaYStepFn)
// Snip - Write pixel value to image array
}
}
// Snip - write image array to canvas
}
As you can see, the functions returned by calling makeJuliaXStepFn
and makeJuliaYStepFn
outside the for
loop are passed to juliaIter
which then does all the hard work of calculating the colour of the current pixel
When I looked at this structure of code, at first I thought "This fine, it all works nicely; so nothing wrong here"
Except there was. The performance was much slower than expected...
Much head scratching and fiddling around followed...
After a while, I discovered that if I move the creation of functions juliaXStepFn
and juliaYStepFn
inside either the outer or inner for
loops, then the performance improves by a factor of between 2 and 3...
WHAAAAAAT!?
So, the code now looks like this
const juliaCalcJS =
(cvs, juliaSpace) => {
// Snip - initialise canvas and create a new image array
// For each pixel in the canvas...
for (let iy = 0; iy < cvs.height; ++iy) {
// Generate functions for calculating the current Julia Set
let juliaXStepFn = makeJuliaXStepFn(juliaSpace.mandelXCoord)
let juliaYStepFn = makeJuliaYStepFn(juliaSpace.mandelYCoord)
for (let ix = 0; ix < cvs.width; ++ix) {
// Translate pixel values to coordinate space of Julia Set
let x_coord = juliaSpace.xMin + (juliaSpace.xMax - juliaSpace.xMin) * ix / (cvs.width - 1)
let y_coord = juliaSpace.yMin + (juliaSpace.yMax - juliaSpace.yMin) * iy / (cvs.height - 1)
// Calculate colour of the current pixel
let thisColour = juliaIter(x_coord, y_coord, juliaXStepFn, juliaYStepFn)
// Snip - Write pixel value to image array
}
}
// Snip - write image array to canvas
}
I would have expected this seemingly insignificant change to be somewhat less efficient, because a pair of functions that do not need to change are being recreated each time we iterate the for
loop. Yet, by moving the function declarations inside the for
loop, this code executes between 2 and 3 times faster!
Can anyone explain this behaviour?
Thanks
V8 JavaScript engine was initially developed for Google Chrome and Chromium web browsers to improve the performance of JavaScript execution. The project's creator, Lars Bak, created the first version that was released at the same time as the first version of Google Chrome in September 2008.
Originally, JavaScript was written to be executed by web browsers. Chrome V8, or just V8, can execute JavaScript code either within or outside of a browser, which makes server-side scripting possible. Like a V8 (eight-cylinder) car engine, Chrome V8 is fast and powerful.
The V8 engine uses the Ignition interpreter, which takes in the Abstract Syntax Tree as the input and gives the byte code as the output, which further proceeds to the execution phase. When the code is being interpreted, the compiler tries to talk with the interpreter to optimize the code.
My code managed to fall off a known performance cliff in the V8 JavaScript engine...
The details of the problem and the fix are described on bugs.chromium.org
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With