After the “Mulligan Year” of 2021 I was hoping that things in 2021 would get a bit less crazy and thus be able to focus a bit more. In many ways things did get less crazy. Vaccinations became available way earlier than I could have possibly hoped. The mind I had for my optimistic date was fourth quarter of the year. That meant I was able to do stuff like register for a race. It also meant that I made up for lost time in the socialization department, which had some knock on effects with my health statuses.

Okay this posting each day a topic seems like a neat thing even if I’m not on WordPress any longer. So will do it as well. Their Day #1 topic is “What advice would you give to your teenage self.

As I’m starting to travel more while simultaneously seeing a ramping up in software development work I’ve had to consider my laptop situation. I prefer to do most of my work on Linux thus my I need a solid Linux environment on the road. I have a “nice” Gen1 M1 MacBook Pro laptop but for it to fill that role it needs to be able to at least run it in virtualization. My Linux laptops are either long in the tooth (my trustworthy System 76 Galago Pro from 2016) or woefully under powered for development tasks (my PineBook ‘Pro’ ). It was therefore time to decide whether I needed to ditch the Mac for a new Linux laptop or see if I could make a go of it with virtualization technology. I got this M1 MBP when it was first released. I tried virtualization at that time and the situation was not good. In the mean time Parallels Desktop has come a long way. While there are some other options which I dabbled with over the years they didn’t provide enough “just works” for me out of the box. For this experiment I therefore decided to try my hand at using Parallels intensely on my holiday travel trip to see if I can make a go of it. Early results seem mostly promising.

While searching for some other information on Dart performance I accidentally tripped across Nikolay Botev’s blog post on the Dart benchmarks against the JVM, JavaScript, and C . It is part of a suite of benchmarks that the Dart language team has created, here is the GitHub project for the benchmark repository . The one he concentrated on was the DeltaBlue algorithm benchmark. The DeltaBlue benchmark is originally a SmallTalk constraint solving problem documented in the January 1990 issue of “Communications of the ACM” paper “The DeltaBlue Algorithm: An Incremental Constraint Hierarchy Solver” by Bjorn N. Freeman-Benson and John Maloney. The version he implemented here is an intentionally crude transliteration of the original SmallTalk code into Dart, JavaScript, and C. It’s been 7 years since he wrote that blog post and the performance page on the Dart language page is long gone. I thought it’d be interesting to see how the performance of the different engines has evolved. There are some interesting results and one interesting performance paradox I want to explore more.

Time flies especially as holidays are coming through, doesn’t it? A couple weeks ago I posted about the Kyanite Beta 2 release . It was about a month ago that I introduced the first beta of Kyanite . Today the third beta release. This is the one that I consider to be feature complete for a 1.0 release. Coming out of the second beta the two big features I wanted that were missing were link previews and the ability to look at posting statistics. There are some other features, tweaks, and bug fixes in this release as well. You can get the latest version for download here .

The first post on Dart benchmarking that I mentioned in this previous post is going to be on the minimum application footprint in terms of application memory and total run time. This exploration began as a side shoot of my benchmarking study when I was noticing some run time oddities for very short lived processes. From there I figured I might as well document the minimum file size, memory size, and run times. As part of this I’m going to be documenting the frequent extend pause in shutting the Dart processes down that often seems to add 1-3 seconds.

It is in my nature to get into the weeds on system performance. It’s part of the engineer in me that likes quantifying things that can be quantified and trying to figure out what is going on based on that. As I’m diving deeper into Dart and Flutter I’m finding myself doing exactly that. It was originally just one little thing I was studying. Then it turned into a much bigger thing which spun off two other studies. That was on top of a few other language specific quirks that I identified earlier this year. Since it’s going to be many posts over time I wanted to put up this post to explain my reasons for doing this. I also wanted to get ahead of one false notion about benchmarks. I’m not doing this to prove that Dart is the fastest leanest language of them all (spoiler alert, it’s not) but just to quantify behaviors and document that.

I decided to take a bit of a shortcut on adding link previews to the Kyanite Facebook archive viewer. Rather than write the whole thing from scratch I figured maybe there was an OpenGraph rendering library already out there. Turned out there were a few for reading/parsing OpenGraph metadata, not that that is too hard either, but one which seemed okay at rendering it, link_preview_flutter . After a little playing it seemed to mostly “just work” but it was choking on cases where there wasn’t OpenGraph data or images in the data. I decided to be a good open source citizen and fork it to tweak it to handle those cases. That’s where my concern began.