Forem: Giles Dring

Optimising Javascript function performance

Giles Dring — Sun, 26 Feb 2023 18:22:52 +0000

I recently solved a coding problem that had been near the bottom of my to-do list for ages. I even managed to shoehorn a recursive function into the solution. Yay, computer science! I walked away, feeling like a job well done... but something didn't feel right. I suspected that my excitement at using a cool technique had resulted in a less efficient algorithm. I'd need to run some experiments to see if my suspicion was correct.

As I was using Deno, I decided to use the built-in benchmarker tool, and set to work coding up my test suite.

The reference function

The recursive function that I wrote was to resolve and return a location in a nested object tree, in exactly the manner of the Lodash get method. I wanted to reduce my dependencies on external functions, so decided against just importing, and it turned out to be fairly trivial to do:

export function arrayWise(ref, context) {
  const [key, ...rest] = ref.split(".");
  if (rest.length) {
    return arrayWise(rest.join("."), context[key]);
  }
  return context[key];
}

So far, so good. Grab the reference, split to an array on the . character, check if there are still levels to descend and if so, descend into them, passing the shortened key and resetting the context for the lower level. If not, return the looked up value from the context. This return would bubble up through the call stack and be presented as the result of the original call.

First alternative

That repeated spliting and joining the ref variable bothered me. How efficient is that as an operation?

With some light tinkering, I came up with this alternative, which was a little more surgical in splitting the string:

export function stringWise(ref, context) {
  const cutMark = ref.indexOf(".");
  if (cutMark === -1) return context[ref];
  const key = ref.slice(0, cutMark);
  const rest = ref.slice(cutMark + 1);
  return stringWise(rest, context[key];
}

This time, we find the location of the first . in the string. If there is none, just return the data referenced by the object. If not, determing the key and rest using the slice method. Then return the result of calling the next layer down.

Writing the benchmarks

Let's see how this stacks up in terms of performance.

Writing the benchmarks is a breeze! I've omitted the imports and setting up a test context object for brevity. Note that the arrayWise function is set up as a baseline case.

Deno.bench({
  name: "arrayWise",
  baseline: true,
  fn: () => { arrayWise("look.me.up", context) 
});

Deno.bench({
  name: "stringWise",
  fn: () => { stringWise("look.me.up", context) }
});

This is saved in a file called lookup.bench.ts. When you run deno bench the command prompt churns away for a few moments then produces an output like this:

My instinct was correct. I've managed a threefold increase in speed of my algorithm. That was definitely a "first, worst" attempt.

A second alternative

At this point, I began feeling uneasy about the recursion. Calling a whole new function felt like a fairly heavy thing to do. Would it be faster to write this as a loop? Back to the code editor and I came up with this:

export function nonRecursive(ref, context) {
  let result = context;
  for (const key of ref.split(".")) {
    result = result[key];
  }
  return result;
}

This time, I'm looping over the keys in the reference within this function, reassigning the result each time. By the time I'm at the end of the loop, I've got my answer, so I return it.

I added the new benchmark into the file, and ran deno bench again. Here are the results this time:

Another speedup, nearly double the speed of the first optimisation. Turns out recursion, whilst a cool technique, is sometimes overkill, and generally best avoided in the case of linear processing such as this example.

A final alternative

I thought I'd see what happened when I placed my typical (very terse) javascript writing style on the bench.

export const extremeGilesMode = (ref, context) =>
  ref.split(".")
     .reduce(
       (result, key) => result[key],
       context
     );

A one-liner! I'll be the first to admit, that this is much less readable than the previous example. It splits the ref string into constituent parts, and then calls the reduce array method on the resulting array. This iterates over the array, returning the key property from the previous result each time. The second argument to reduce sets the initial value of the result. In this case, we set it to context. This is the pretty much the same technique as the nonRecursive function.

It's terser, but is it any faster?

Not really faster, and looks like it might be slightly slower. The nonRecursive implementation is the fastest.

What did I learn?

This was an informative experiment to run. In this case, It would probably have been fine to leave the initial implementation, given the savings per iteration were measured in nanoseconds. Mind you, had that been called many times, it could have been a significant performance slowdown.

Worth noting also that each run gives a different time per iteration, so careful about citing definitive numbers. When analysing performance, it's worth looking at the percentile figures (p75, p99 and p995) to check for variability.

Overall, I was really impressed with how easy it was to set up benchmarks in Deno. There are some limitations for those who are used to benchmarking, but as a starter set, it's pretty powerful.

I've bundled up the examples in a Github repo. Let me know via the comments what performance improvements you've make to your code.

Making iframes work better

Giles Dring — Thu, 05 May 2022 20:04:47 +0000

The humble <iframe> is a useful way of presenting content from another web page, but can be quite difficult to make work seamlessly. This short article presents a way of making them a little easier to integrate into a responsive design.

Setting up an iframe

Adding some nested content is as simple as adding an <iframe> tag with a src attribute pointing at the content to include.

<iframe src="/nested-content.html"></iframe>

Out of the box, this leaves a little to be desired - notably the height and width take no notice of the size of the host page or the nested content!

The width is fairly easily fixed by setting the width of the iframe element to 100%. The quickest way to do this is with a default size.

iframe { width: 100%; }

How tall is this iframe?

The height is a slightly different matter. While it is possible to set height the same way (or via an attribute on the iframe), there's the question of how large that should be. Ideally we'd set this to the height of the iframe content, but there's no foolproof way of knowing this. For a simple nested page it's fairly easy.

#nested-content { height: 5.5rem; }

This looks much better! There's a problem though: this is a fixed height, so the content will not respond to changes in screen size or content in the nested page. If the content is longer than the size we set, we end up with a scroll bar in the iframe, which may not be what we want.

Making the height responsive

The good news is, we can achieve this dynamic resizing using a trivial amount of JavaScript! Because of limitations introduced by CORS (Cross-Origin Resource Sharing) to prevent attacks, we have to use the postMessage() method to safely share information between the parent and nested page.

The basic flow is to calculate the size of the nested page using the getBoundingClientRect() method of the top-level element of the nested page. This is accessible using document.documentElement. We then message the parent page with the new height. An event listener makes this reactive to changes in height of the page.

function sendResizeMessage() {
  const height = document.documentElement
    .getBoundingClientRect().height;
  parent.postMessage({ height }, parent.location);
}
sendResizeMessage();
addEventListener('resize', sendResizeMessage);

All we need to do now is listen for this message in the parent page, extract the height and set the iframe size accordingly.

const iframe = document.getElementById('iframe-id');
addEventListener('message', (event) => {
  const height = event.data.height;
  iframe.style.height = height + 'px';
});

Like good citizens, these are both loaded in DOMContentLoaded handlers.

addEventListener(
  'DOMContentLoaded',
  <initialisation code here!>
);

Making it a bit more secure

Although the code we're running is fairly harmless, there is a possibility that someone could message us and set the height of the iframe. The postMessage() documentation suggests confirming the sender's identity by checking the event source and origin.

The updated message listener now looks like this:

const iframe = document.getElementById('iframe-id');
addEventListener('message', (event) => {
  if(!(
    event.source === iframe.contentWindow &&
    event.origin === 'https://example.com'
  )) return;

  const height = event.data.height;
  iframe.style.height = height + 'px';
});

All we've done here is to test that

the event source is the iframe content window
the event origin is the expected url

Note that this is negated so if it doesn't match, the function returns early.

I've got a slightly more fully worked out example in the iframe-resizer repo on GitHub, and you can see it in action.

I hope this has been helpful, and thanks for reading!

Svelte test suite setup

Giles Dring — Thu, 27 Jan 2022 13:31:27 +0000

I love writing with Svelte. It’s pretty simple to learn and you can build quite complex and robust behaviour really quickly. The support and documentation is also awesome: being able to create a basic project with degit means you can be productive even faster.

One thing that’s missing from the template project is a starter test suite. This means I’ve never really tried to write any automated tests against my Svelte code. I’ve definitely written large apps that could have done with this level of support. I decided to look into how to do it.

Turns out that it’s actually reasonably easy to get testing set up, although not without its challenges. This brief guide will take you through what worked for me!

Test runner

Firstly, we need to pick a test runner. Jest is a great choice because it's simple to get running and includes a bunch of useful utilities like mocks and assertions.

npm install --save-dev jest

You'll need to add a couple of extra scripts into your package.json. These scripts assume that your source files (and the location of your tests) will be in the src folder.

  "scripts": {
    ...
    "test": "jest src",
    "test:watch": "npm run test -- --watch"
  }

You should now be able to run the test suite by typing npm test. It'll fail, because you have no tests set up, as yet.

Babel

If you're using ES6 modules (i.e. import statements), which you probably are if you're using Svelte, you'll also ned to install Babel to convert into code that's compatible with Jest.

npm install --save-dev babel @babel/preset-env

Create a Babel config file. I prefer to create a Javascript file babel.config.js at the root of the project. NB I tried to use an .mjs file, which would theoretically allow ES6 exports, but this appeared incompatible with usage within Jest.

module.exports = {
  presets: [
    [
      '@babel/preset-env',
      { targets: { node: 'current' } },
    ],
  ],
};

Setting up test libraries

We're nearly ready! The last step is to install some test helpers and configure Jest to deal with .svelte files.

npm install --save-dev babel-jest svelte-jester \
  @testing-library/jest-dom @testing-library/svelte

Create a jest.config.mjs file (this time the ES6 format works!) and add the following configuration:

export default {
  transform: {
    '^.+\\.js$': 'babel-jest',
    '^.+\\.svelte$': 'svelte-jester',
  },
  moduleFileExtensions: ['js', 'svelte'],
  setupFilesAfterEnv: ['<rootDir>/test/jest-setup.js'],
  testEnvironment: 'jsdom',
};

Create the file test/jest-setup.js and add the following content.

import '@testing-library/jest-dom';

This will register the additional assertions from @testing-library/jest-dom.

The transform config sets up babel-jest to deal with .js files and svelte-jester to deal with .svelte files.
The moduleFileExtensions key registers both js and svelte files as valid source code for testing.
setupFilesAfterEnv loads the setup file we created.
Finally, we set the default Jest test environment to jsdom as we'll primarily be working in code targetted at the browser. As stated in the documentation, it's possible to override this for individual test files by adding a @jest-environment docblock at the top.

Write some tests!

Let's say you have a simple Svelte component called hello.svelte.

<script>
  export let name;
</script>

<h1>Hello { name }!</h1>

Create a test file in the same location called hello.test.js

import { render } from '@testing-library/svelte';
import Hello from './hello';

it('should welcome mum', () => {
  const { getByText } = render(Hello, { name: 'mum' });
  expect(getByText('Hello mum!')).toBeInTheDocument();
});

This imports the render function from the @testing-library/svelte helpers. We use this to instantiate the component, passing in any props as the second argument. In this case, we're setting the name prop to mum.

The render function returns a object with a series of helper functions. Here, we're only interested in getByText, which we destructure from the object.

This searches for elements in the rendered DOM which match the text. In this case, we're looking for an element with the string Hello mum!. We wrap this in a Jest expect call, using the toBeInDocument matcher that we registered from jest-dom to check if the text appears.

Write some more tests!

That's pretty much it. You now need to make sure you're covering all the critical bits of code that you care about! That's beyond the scope of this post, but here are a couple of links to get you started.

As a final thought, one of the tricks that Jest has up it's sleeve is built-in test coverage reporting. Run npm test -- --coverage to get a report on how much of your code is covered.

You'll notice that you only get coverage stats for code that you're importing into your tests, which means that you could develop a blind spot for modules which you've not yet started.

To fix this, add the following line to the jest.config.mjs file.

  collectCoverageFrom: ['<rootDir>/src/**'],

You'll now see other .svelte and .js files listed. Get to work on writing spec for your code! For more details on which code is currently tested, you can open the lcov report that is created for you in coverage/lcov-report/index.html.

NB I found that coverage reporting sometimes failed unless I added the following line into the Jest configuration. If you have problems, give that a try.

  testMatch: ['<rootDir>/src/**/*.test.js'],

Thanks

I hope you've found this article useful. Let me know if you have any other hints for testing Svelte code in the comments below.