Electron Adventures: Episode 64: Measuring Performance

Hex editors routinely deal with fairly big files. Unfortunately when I tried to load big files into ours, it took forever to start.

It was actually very responsive after it got started, so the startup performance was the only problematic area.

Sample files

I prepared a bunch of files in samples/ with various files, and selected different one in preload.js like this:

let fs = require("fs")
let { contextBridge } = require("electron")

let data = fs.readFileSync(`${__dirname}/samples/1024.bin`)

contextBridge.exposeInMainWorld(
  "api", { data }
)

As our app loads all files equally, except for some logic changes depending on printable vs non-printable characters, I simply copied over our original 4kB sample required number of times to get size I wanted.

Performance measuring code

Svelte makes it fairly easy to measure when it started, and when it's done updating the DOM. The tick callback happens once Svelte is done.

From what I've seen this is not quite when browser shows the content, but it covers most of the wait time.

  import { tick } from "svelte"

  let t0 = performance.now()
  tick().then(() => {
    let t1 = performance.now()
    console.log(`Loaded ${Math.round(data.length / 1024)}kB in ${t1 - t0}ms`)
  })

performance.now is recommended over Date due to potentially better accuracy.

How slow is it?

What we got right now is nowhere close to what we want (some representative rounded numbers from a few tries):

• Loaded 4kB in 180ms
• Loaded 16kB in 570ms
• Loaded 64kB in 1850ms
• Loaded 256kB in 7625ms
• Loaded 1024kB in 42135ms

Taking 42s to load 1MB file is definitely not acceptable.

What is taking all that time?

The best dataset to test performance on is one big enough to not be too affected by noise and small stuff, and one small enough that you can iterate without feeling temptation to open TikTok while you wait.

For a quick tests I used 64kB. I had some ideas what might be slow, so I tried commenting out some code. Here's what happens (some representative rounded numbers from a few tries):

• Baseline: Loaded 64kB in 1990ms
• No ASCII: Loaded 64kB in 1440ms
• No Hex: Loaded 64kB in 1130ms
• No mouseover events: Loaded 64kB in 2000ms
• Replaced printf by .toString(16) (which doesn't do zero padding) in Hex: Loaded 64kB in 2250ms

That gives us some idea what to do optimize, and what to leave for now.

In the next episode we'll see how far we can get optimizing the code.

As usual, all the code for the episode is here.