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.

A few weeks ago I introduced the first beta of the Kyanite Facebook archive viewer. Today I’m announcing the second beta release complete with a bunch of bug fixes and new features. My favorite new feature is the map view for browsing/filtering posts that have geospatial information. You can get the latest version for download here .

With the first real world usage of Kyanite came the first bugs. One of the biggest bugs was an apparent memory leak. Part of it was coming from an extraneous image query code that I no longer needed so removed rather than fixed. However most of it was coming from the unlikeliest place. There are a few common text widget types but the two I was using were: Text and SelectableText . SelectableText was used anywhere I wanted users to copy/paste text of posts/comments/etc. It turns out that was the source of not only my memory leak but some performance problems as well.

NOTE: Because of how responsive the Flutter team is there is already a patch in pull request but I wanted to explore this here anyway. The article shows how ListViews are supposed to operate, how one builds performant ListViews with builders, etc. Also until the fix does go into a mainline version it will be important people keep this caveat in mind with SelectableText widgets.

One of the idioms that I started using for function returns was the Result Monad. I first got excited about it when learning Rust, where this is an intrinsic part of function returns. It wasn’t until reading Adam Bennett’s blog post on the Result Monad library in Kotlin that I really felt the impetus to use it in other languages. I don’t always use it, especially in quick/simple things, but for building an API/library I have found it very useful. When coming over to Dart I tried to use something similar. There were some monad libraries or the “Either” concept in functional programming libraries. None of them had the flows and syntax that I liked in my favorite Kotlin Result Monad Library except for one library which looked abandoned and had a Flutter dependency so couldn’t be used in Dart only projects. I therefore decided to write my own and publish it. This post is an exploration of that. The library source code and issue tracker is here with the pub.dev entry here .

NOTE this article is from 2021. There is updated preferred syntax in later release, as covered in this post on the 2.0 release

While working on the Kryanite Facebook archive reader I ran into a frequent problem of garbled text. Ninety-nine percent of the time everything would be fine but then I’d see a string of weirdly out of place characters. I had assumed that perhaps the default encoding picked by the Dart file reader was to blame. Perhaps it should have been UTF-16 instead of UTF-8, or something along those lines. Experimentation didn’t help the problem. It turns out the problem is one of Facebook not properly encoding their files. With the help of another blogger who discovered the problem and fixed it I was able to create Dart code which fixes it for my uses as well. Here is the snippet . Read below the fold for more details.