A look at the last 10 years of implementing HexaPDF and creating a business around it
I have been implementing HexaPDF for the last 10 years now and just released version 1.0.0. It all started due to missing features in an existing library (like with kramdown and so many other things) and an odd desire to implement a largish specification from scratch. Little did I know what that would entail…
The yearly benchmarking Ruby post
It’s this time of the year again where Ruby is released and everyone asks: Is it faster? You will find out below! And if you are interested, you can compare the results to the previous installations of this post for the years 2016, 2017, 2020 and 2021.
This christmas Ruby 3.2.0 was released, featuring improvements across the board. The YJIT just in time compiler has been ported to Rust and can now be used on ARM machines. And variable width allocation (VWA) has been enabled by default. Let’s see how fast Ruby got in the past year!
The yearly benchmarking Ruby post
This is another Ruby comparison benchmark, in the tradition of 2016, 2017 and 2020. This christmas Ruby 3.1.0 was released, featuring the brand-new YJIT just in time compiler. Pre-liminary benchmarks showed noticeable performance benefits for HexaPDF, so let’s see what the final version brings.
How wondering about an odd benchmark result led to better performance
I regularly run the HexaPDF benchmarks to make sure that HexaPDF gets faster and not slower. One of the benchmarks, the “raw_text” benchmark, always had me wondering why using TrueType fonts was visibly slower. So I decided to investigate.
Benchmarking Ruby version with three different benchmarks
I ran some benchmarks using HexaPDF after Ruby 2.4 was released in 2016 and again after Ruby 2.5 was releasd in 2017. Since Ruby 3.0.0 was released this Christmas, I think this warrants another round of benchmarks. And this time three different real-world benchmarks are used to evaluate relative Ruby performance.