1. 7
  1.  

  2. 3

    there’s no machine specs in this benchmark – on its homepage swc essentially claims to utilize cores better than babel. i’d assume babel is worse at parallelizing than either esbuild or swc, but I’d be interested in seeing whether swc or esbuild makes better use of multiple cores.

    esbuild’s own benchmarks show a much larger gap between esbuild and parcel (swc). I can’t tell at a glance whether this is because of different benchmark inputs and different machine or because parcel adds significant overhead

    EDIT: functional comparison (bundle size) would probably make sense to add too. Considering that NextJS is opting for using SWC instead of esbuild even though there’s this much of a performance gap.

    1. 1

      there’s no machine specs in this benchmark

      Good point, thanks! Just pushed it with this detail: It’s a dedicated instance on OVH, OVH Rise-1.

      • RAM: 64 GB DDR4 ECC 2,133 MHz
      • Disk: 2x450 GB SSD NVMe in Soft RAID
      • Processor: Intel Xeon E3-1230v6 - 4c/8t - 3.5 GHz/3.9 GHz
      1. 1

        even though there’s this much of a performance gap

        What do you mean by this? esbuild and swc were basically identical in performance (especially in human timescales) and both much better than typescript and babel.

        1. 2

          right, in your benchmark, but not in the one provided by esbuild. should’ve added “potential”

          1. 1

            Oh I see, thanks for clarifying.

    2. 1

      I find very surprising that esbuild, written in Go, is faster than swc, written in Rust. This is one of the main arguments behind the “rewrite everything in Rust” wave we are having.

      1. 4

        It is possible for an O(n) implementation in Python to outperform an O(n^2) implementation in C. To me, a go program being faster than a rust program at a similar task is not surprising. The program with better data oriented design will come out ahead. I view the RIIR brigade as mostly about safety, anyways.

        Edit: here’s the esbuild FAQ answer for “why is it fast?”, https://esbuild.github.io/faq/#why-is-esbuild-fast

        1. 1

          it seems to me that esbuild is less configurable, but it’s important to keep in mind that the RIIR argument holds insofar as that swc is comparing itself to babel, not esbuild just yet

        2. 1

          Thanks for the benchmarks.

          Minor nit: if you want this to make datastation look good (I didn’t know importing csv into SQLite was so easy, btw. Neat trick!) I would make the charts more readable. The title and legend text is WAY too small on my iPhone.

          1. 1

            I would make the charts more readable. The title and legend text is WAY too small on my iPhone.

            Ah I think that’s just bad blog CSS rather than DataStation itself. It generates a decent sized PNG that I just embedded here and restricted width to 100%. I don’t actually have a solution off the top of my head except for to make the picture a link so you can click on it and see the whole thing?