long delay before and after script execution

I have noticed that importing this library will cause a long delay before my script is executed. I assume the delay before the script executes is because the wasm file is dynamically imported automatically

const Canvas = await lib.CanvasKitInit({}) as CanvasKit;

I do not know why there is an extra delay after my script executes though.

To illustrate how long the delays are, here is a simple benchmark. First the script using your library:

import Canvas from 'https://deno.land/x/canvas@v1.1.1/mod.ts'
console.log(Date.now(), 'imports complete')


const canvas = Canvas.MakeCanvas(200, 200);
const ctx = canvas.getContext('2d');
console.log(Date.now(), 'created canvas & context')

ctx.fillStyle = 'red';
ctx.fillRect(10, 10, 200 - 20, 200 - 20);

await Deno.writeFile('image.png', canvas.toBuffer())
console.log(Date.now(), 'deno wrote buffer to png')

and a bash script timing the usage:

#!/bin/bash

millis() {
  echo $(($(date +%s%N)/1000000)) $1
}

deno install -f --allow-write ./canvas.ts
millis 'before script'
canvas
millis 'after script'

Here is the output:

./timer.sh
✅ Successfully installed canvas
/home/andrew/.deno/bin/canvas
1615473303762 before script
1615473305209 imports complete
1615473305213 created canvas & context
1615473305251 deno wrote buffer to png
1615473308244 after script

Thats a 1.447 second delay during import and a 2.993 second delay after the script finishes executing.

If these delays are absolutely necessary, it would be nice if we could at least control the lifecycle. E.g. instead of implicit importing and cleanup, expose an api for loading and cleanup:

import Canvas from 'https://deno.land/x/canvas@v1.1.1/explicit_lifecycle.ts'

// we choose when to begin the slow load
await Canvas.load()
const canvas = Canvas.MakeCanvas(200, 200);
// do some stuff with the canvas...

// we choose when to perform cleanup
await Canvas.unload()

[DjDeveloperr]

Also found a fix! But kinda hacky. Reduced the decoding overhead from 2.8s to 0.5s by using internal op_base64_decode instead of std’s base64 decode which is pure js.

[DjDeveloperr]

Most of the time as noticed in your benchmarks was taken by base64 decoding, at startup. WASM instantiation takes like 0.6s IIRC. Not sure about “after script execution”, but I suppose that might be background cleanup done for wasm at end by v8 or something.