Why is Bun is 3x slower than node in this data processing benchmark?

[jinyus]

Repo: https://github.com/jinyus/related_post_gen

They are running the same code so this might be worth investigating.

[morkai]

Array#fill is up to 7x slower in Bun:

root@vm:~/related_post_gen/js# cat fill.js 
const t1 = Date.now();
const array = Array(5000);

for (let i = 0; i < 5000; ++i)
{
  array.fill(0);
}

console.log(Date.now() - t1);

root@vm:~/related_post_gen/js# node fill.js 
21
root@vm:~/related_post_gen/js# /root/.bun/bin/bun fill.js
141

[jinyus]

Nice catch, manually filling the array cuts the time by half. Node and Deno is still ~1.9x faster

https://github.com/jinyus/related_post_gen/blob/c5a71f48510b8b2a776e20015d6200561441e7c3/js/related.js#L22

[morkai]

Replacing forEach and for of with for i speeds things up too.

110ms +/- 10ms avg in Node 20.8.1 on my PC (the original was 150ms).
70ms +/- 10ms avg in Bun 1.0.4 (the original was 450ms).

export function genRelatedPosts(posts) {
  const postsCount = posts.length;
  // build a map of tags to post indices. tag -> [idx1, idx2, ...]
  const tagMap = {};
  for (let i = 0; i < postsCount; i++) {
    const post = posts[i];
    const tagsCount = post.tags.length;
    for (let j = 0; j < tagsCount; j++) {
      const tag = post.tags[j];
      if (tagMap[tag]) {
        tagMap[tag].push(i);
      } else {
        tagMap[tag] = [i];
      }
    }
  }

  const taggedPostCount = new Array(postsCount);
  const allRelated = new Array(postsCount);

  for (let i = 0; i < postsCount; i++) {
    // fill array with 0s manually. Array.fill() is slow in bun
    for (let j = 0; j < postsCount; j++) {
      taggedPostCount[j] = 0;
    }

    const post = posts[i];
    const tagsCount = post.tags.length;

    for (let j = 0; j < tagsCount; j++) {
      const other = tagMap[post.tags[j]];
      const otherCount = other.length;
      for (let k = 0; k < otherCount; k++) {
        taggedPostCount[other[k]]++;
      }
    }

    taggedPostCount[i] = 0; // exclude self

    const top5 = new Array(5);
    for (let j = 0; j < 5; j++) {
      top5[j] = {post: null, count: 0};
    }

    let minTags = 0;

    // custom priority queue to find top 5
    for (let j = 0; j < postsCount; j++) {
      const count = taggedPostCount[j];

      if (count > minTags) {
        let pos = 4;

        while (pos >= 0 && count > top5[pos].count) {
          pos--;
        }

        pos++;
        top5.splice(pos, 0, {post: posts[j], count});
        top5.pop();
        minTags = top5[4].count;
      }
    }

    allRelated[i] = {
      _id: post._id,
      title: post.title,
      tags: post.tags,
      related: top5.map(p => p.post)
    };
  }

  return allRelated;
}

[jinyus]

Interesting. 132% increase for bun.

jinyus/related_post_gen#279 (comment)

[TheFanatr]

Hmmm, I still do think it concerning or, at the very least, significant that Bun really is slower in these tests with in-built functions. I think the Bun team should take that seriously, as real-world libraries may not think to use these optimizations, and thus actually lead to slowdowns inadvertently if Bun is used ignorantly by a consuming project of the library, with only partial opacity as to why; tracing does not necessarily provide fixes, although they can be searched-for and found here, obviously, but this does not mean that will happen or be useable by a library consumer, and it doesn't explain why this happens to Bun in this scenario and probably a lot of others as well.

Makes me also wonder why this is the case, and why whatever speedups exist for this specific syntax can't simply be deferred-to, automatically, within Bun. Surely ForEach is implemented with for <!#item#!> of <!#iterable#!> { }?

A little concerning if everything is special-cased like that, because then benchmarks testing only one language feature or in-built to do the same thing will misrepresent the relative performance of these tools.

Maybe an issue should be made for this, OP? I might make one, and should link it here if I do.

[masterbater]

Then forof and forin, and foreach should be fixed