Advanced Random Slower than Javascript

We've been working on a perlin noise generator through javascript, and were super excited to get the webassembly version of it in the new C3 runtime.

Running pretty much the SAME code, between the two, the advanced random plugin takes almost 3x as long that the javascript one. All we're really doing is generating a 2d classic noise and sending that value through a return function.

Changing the octaves didn't seem to have any difference, either.

Any help or insight would be appreciated!

Hey there, I'm the dev who wrote the Advanced Random plugin.

What you're kinda discovering here is that despite what people are saying, WASM isn't a silver bullet for performance. Side by side code performance for WASM and well written JS can be pretty similar. It doesn't help that most browsers have an noticeable cost when you call into WASM from JS. The browser developers are still improving things here so in a years time we could see fairly large improvements, but it's hard to say how big an improvement. Firefox can already run WASM code much faster than Chrome, so hopefully we can at least see parity at some point.

Could you tell me a little more about how your using your noise? Or possibly provide the project/s so that I could compare performance?

I have a few ideas that could improve performance. Also we're still early days on this plugin so user feedback is much appreciated.

The project is mostly a performance test of event loops vs. JavaScript loops. Events have quite a high performance overhead for things like tight loops, so that's probably all you're measuring.

Taking a look at it now for you; got 3 things for you so far.

First thing is that inside your CreatePerlinNoise function you are attempting to read the scale from index 3 instead of 2. This out of range read is causing a HUGE amount of warnings in the browser console, which is why it's running so slow. Fixing this got me down to a 3 second run.

Second you don't need to provide your seed in the expression, the plugin already uses a seedable PRNG internally. By default it uses a random seed. You can set it using the Update Seed action, but it can also be set as a property of the object through the editor. You can use the Seed expression to get the current seed, and you can use the RandomSeed expression to create a new random seed.

Finally your setting your octave count once per iteration, it only needs calling when you want to change it.

Nepeo - wow, talk about an oversight! That totally makes sense why it was taking so long.

You are a lifesaver! Thank you.

Nepeo

Ashley

So I've now gone back to my original project, and did the changes based on what Nepeo suggests, and instead of 27 seconds, it only takes 9-10 seconds! Which is a huge improvement, but I tried disabling every line of code except for the "for" loops, and it takes around 7-8 seconds just to process that many repeats.

It could be because there are now more events in play, but would there be another reason for this, Ashley?

I actually have a project which you could use as a reference here

https://www.dropbox.com/s/azb5fxpcfrzp6m0/animated%20terrain.c3p?dl=0

While it looks different it's working in much the same way as your project was. It's iterating over a tilemap using 2 loops ( using repeat in this case ) generating a noise value per tile, and using that to decide what tile to use.

My value calculation line does some math which you probably don't need to look at, but otherwise this is a fairly optimal way to use the plugin.

Looking back at your project, I'm not sure how your applying it in the full version but your tilemap is roughly 108 * 60 tiles ( ~6000 ) comparing this to your event sheet your generating 1000 * 1000 tiles ( 1000000 ). Which means your doing more than 2000 times more work than you need. If you do need that many tiles you will find it much faster to generate the tiles in small patches as you need them ( generally within view of your character ). My terrain example generates just under 15000 tiles per frame and runs at a nice smooth 60fps on my computer, and that's using the slower 3D noise which an additional octave.

You probably know this but perlin noise is effectively persistent, being that given the same seed and the same input values it will always give the same number back out.

Nepeo - I get a "Failed to Open Project. Check if it's a valid c3p project" when I import to c3.

Yes, I left the tilemap whatever default size it was when it imported; the actual tilemap in the game is 1k x 1k. We thought about doing small cells of loading as you needed them, but it still created a second or two hiccup in the game.

Sorry about that, I last opened it in a debug build. The release version didn't understand part of the project, you should be able to open it now?

Nepeo - yeah this seems similar to what we're doing. The only difference is that your repeat loops take MUCH less time (almost 1/10 of the time) as ours does in our game. In a brand new project, it's fine, but the second we loop through a 1k x 1k array, it hangs for around 10 seconds.

I've even tried doing this on an empty layout with no event sheet includes.

I think this is more of an Ashley question - is there any particular reason for that? There are some art assets in the game, but at an extremely small pixel scale.