Blog - Binary Sky

Why is the app slow on Pixel 7?

Mon, 26 Jan 2026 00:00:00 GMT

So a collegue comes over to me one day to ask what changes we did since the last release, reason being: "The app is very slow on Pixel 7 running on <cloud-based emulator service>".

As I, too, am addicted to being useful, I get curious and sympathetic to their call for help. I suggest we should try a debug build instead to get a profile trace. But instead, we get... a crash? Cannot locate symbol _ZTVNSt6__ndk118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE in libc++_shared.so.

After a while of looking through the logs and trying bumping different versions without having any effect on the issue we read something at the start of the log that really has been staring us in the face this whole time... the emulator is running on x86_64. Suddenly a lot of things start to click. The emulated "Pixel 7" device isn't really anything like the actual physical device. Now we have some actual technical reason that could begin to give an explanation to the symptoms of the bug.

Looking into the actual APK file, we can see that the only provided .so files are for ARM-v7 and ARM64. This is because we recently worked on optimizing the APK file size and removed support for architectures other than ARM. So I figured all problems would be solved by just re-enabling x86, but no luck - the crash was still there even though we now have included specific libs for x86_64. Maybe there was some difference between them? But regardless from all this: how did the app even launch at all if the native files for the architecture was missing?

Together with Claude we made a shell script that inspects the symbol table inside libc++_shared.so artifacts and searches for the specific symbol name that was missing. All intermediary files matche, but some of our vendors provide prebuilt .so files inside of .aar (Android library archives) files - let's check those as well... And bingo, we finally found where the outdated libc++_shared.so file comes from!

During the APK assembly step, there can only be one of each native artifacts, and for reasons unbeknownst to man, gradle consistently picks the prebuilt one that is outdated instead of using any of the freshly built ones. I didn't have any luck configuring gradle to skip this one or to prefer any other artifact, and another teammate informed me that our vendor fixed this in a later release by letting us providing libc++_shared.so and not embedding it within the archive.

So finally we are back to debugging the original issue, the slowness. But when we start the app again, not only is there no crash at startup — the app is fast! ...what?

Somewhere in this debugging rabbit hole we actually solved the original bug? This is where we go though and cherry-pick all the changes one by one to a new branch, and it turns out that the relevant change was... enabling x86_64 support?

Claude helped me to connect the dots, I gave it all the symptoms and details of the debugging session this was the short answer:

Android emulators use ARM-to-x86 translation technology (sometimes referred to as libhoudini in the community) that allows ARM apps to run on x86 hardware, though with significant performance overhead

Finally we had a solution to both and which also answered how the app even worked on x86 to begin with: The app was emulated through an additional translation layer. I also found this blogpost by Google that mentions this being a thing.

All in all, sometimes it really pays off to dive deep into issues that only happens on an esoteric configuration of a Pixel 7 device. I learned a lot on this journey where what seemed to be a bug was actually a feature.

My Advent of Code in Roc 2023

Fri, 02 Feb 2024 00:00:00 GMT

It starts like it always does. Everything is fun and games before they hit you with the algorithm-heavy days. And then you can't muster up the strength to keep up anymore. And then you give up. But I still mostly scraped by until day 20 (skipping 14 and 17, which I keep telling myself I will get back to anytime before next December).

At least my language of choice gave me an interesting extra challenge of solving the task in a way that the compiler likes. I.e. doesn't panic or crash without giving any output. — Jokes aside, as December went on I learned the tricks to work around the compiler bugs and crashes, and I’m sure the Roc language developers got a fair share of bugs to squash until next year.

Recursive mindset

Roc doesn't even have iterative loop constructs like for or while, instead it relies on recursion, which can be a bit getting used to. But Roc promises the same benefits in terms of runtime performance and memory usage using a combination of different strategies — sometimes the compiler can just replace the recursive call with a loop, and in more advanced cases you are encouraged to use tail-recursion. The upside of being forced into thinking in terms of recursive algorithms is that they can sometimes be a bit easier to understand and implement when reading Wikipedia’s pseudocode.

Aside from recursion, I also learned a bunch of useful stuff, like the Shoelace formula, which calculates the total area of a polygon from the set of points, Karger's algorithm, which can be used to "min-cut" a graph, and of course our old pal Dijkstra made some appearances.

What’s next?

Roc is implemented in part with Zig which piqued my interest and I would enjoy investigating it further, but in another project.

My month of Roc got me into making a (slow as molasses) Ray tracing renderer while following along the Ray tracing in one weekend e-book. Both The Cherno and Sebastian Lague were great resources along the way with great visualizations to help further my understanding. Maybe I should try making a renderer using Ray marching next?

I just finished my third week as an independent consultant, and next week I'm going skiing which right now feels like a much-needed break from everything.

Val.town

Thu, 30 Nov 2023 00:00:00 GMT

If you're like me, you've probably run into the case that you need to run scripts every week, day or every hour. Maybe you want to monitor the daily scoreboard of Advent of Code. Maybe you want to post the status of the Strava running challenge to a Slack channel each week.

I found val.town on hacker news some time ago and have since ported all my scripts to use it.

In this post I have collected some example use-cases:

Monitor Advent of Code score board

Every day in December (at 12, to give everyone a chance to solve the puzzle), we post the scoreboard to the #aoc work Slack channel. First there is the time challenge - and later the total stars.

Advent of Code does provide an API which just requires cookie authentication. - Easily achiveable with val.town.

Summarize the Strava challenge

Every week, we post the current leaderboard of the local running group to a Slack channel.

This is slightly more involved, since Strava does not provide an API anymore. We have to scrape the website and parse the HTML to provide a plaintext representation of the current standing.

This integration also needs to store state, since we want to know if someone has improved their score since last week.

Val.town provides a simple key-value store which can be used for this.

import { blob } from "https://esm.town/v/std/blob?v=3";

await blob.setJSON("stateExample1", { foo: "bar" });

await blob.getJSON("stateExample1");

Find available online booking times

It all started when I got a gift card from my parents for a barber shop. -- I wanted to book an appointment, but no times were available for the next 2 months.

Using the browser devtools I inspected the JSON API and wrote a script that calls the API every hour, and send a push notification to my phone when an earlier time would appear.

I ended up getting a time in about a week.

Advent of Code 2023!

Fri, 24 Nov 2023 00:00:00 GMT

It's almost time! Just one week left to Dec 1st: adventofcode.com/2023.

My goal this year is to learn a new programming language, if not only because then I can put the blame on something else when I inevitably crash and burn somewhere around day 15 given my current track record:

2015      12
2016      10
2017      11
2018       8
2019      10
2020      22
2021      15
2022      22

You can follow me along on GitHub where I will be posting my solutions: lindskogen/advent-of-code-2023

For myself, I haven't decided what language to use yet, but I usually go with Rust or Kotlin. But this year I might try something else, like Gleam or Roc. Both of them are functional languages and I find that the functional style of programming is well suited for AoC.

Gleam

The main selling point of Gleam — as well as Elixir — is making the Erlang VM + Ecosystem accessible to more users and without them having to learn the absolute travesty that is the Erlang syntax.

I've had some time to play around with Gleam and the syntax is a bit verbose but it's not too bad. It's also similar to Rust, which I like.

Roc

I appreciate languages that try to make them accessible for beginners. The prime example of this is Elm. Roc claims to do the same and I'm excited to try it out! It's a bit intimidating to learn all the new syntax but I enjoy exploring new ways of thinking about programming.

Roc is more in the vein of Haskell, and like Haskell, it handles arbitrarily large integers out of the box. Sometimes that gives you an edge in the AoC puzzles.

There also seems to be a story for "async in Roc" from the start. I feel that this is almost a requirement for new languages these days, since most applications needs to call out to external systems or do some other async task.

Update: For anyone else looking to try Roc for AoC, @rtfeldman posted a guide here: Link to GitHub Gist

CSS Grid – force columns to be the same width

Mon, 20 Nov 2023 00:00:00 GMT

We used to do a lot of column-based layouts at work — which I implemented with CSS Grid.

.grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

This example can be customized to any number of columns by changing the 3 in repeat(3, 1fr).

All was fine initially, but designers complained of inconsistent column widths on certain screen sizes.

After some research, I stumbled over this solution and it works great!

.grid {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
}

As stated in the answer, the minmax(0, 1fr) function makes the columns be between 0 and 1fr and forces the columns to be the same width.

Bonus tip!

----------------------
|      |      |      |
|      |      |      |
|      |      |      |
----------------------
|      |      |      |
|      |      |      |
|      |      |      |
----------------------
|      |      |      |
|      |      |      |
|      |      |      |
----------------------

For a grid that needs single-pixel borders between the columns and/or rows, you can use the gap property together with background-color and it will keep working even if wrapping occurs.

.grid {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  gap: 1px;
  background-color: black;
}

.grid > * {
  background-color: white;
}

Today I quit my job and started working as an independent consultant

Tue, 14 Nov 2023 00:00:00 GMT

Many old colleagues wished me luck with my future plans.

I cooked! Today I made Korv stroganoff — it is one of my favorite dishes and I like to keep improving my cooking skills.

We also did some budgeting to make sure that we could pay rent and survive for the months I wouldn't get any salary.

Also, I did something probably many other people did this week — I switched my coding font to a Monaspace variant. For my editor I used Neon, and for a bit of fun, I used Argon for iTerm.

TWIL

If you want to pack up an entire git repository (just the staged and committed files) as a zip file, you can use the following command:

git archive -o output.zip HEAD

Apparently, you are allowed to put @media-queries inside svg style elements. Combine this with the prefers-color-scheme media query and you can make svgs with built-in support for dark mode!

Very useful for text!

<svg viewBox="0 0 100 100">
  <style>
    @media (prefers-color-scheme: dark) {
      circle {
        fill: white;
      }
    }
  </style>
  <circle cx="50" cy="50" r="40" />
</svg>

And it even works inside img tags: <img src="icon.svg"/>!

GraphQL Subscriptions with Apollo Supergraph

Fri, 10 Nov 2023 00:00:00 GMT

Together with a colleague, I set up an Apollo Supergraph that includes support for GQL subscriptions.

graph TD
    A[Gateway & Websocket Proxy] --> HTTP --> B(GraphQL Server)
    A --> WebSocket --> C(Subscriptions Server)

Details of the supergraph

We put the old GraphQL server and the subscriptions server behind the gateway server, and then we set up a WebSocket proxy server to proxy the connections to the subscriptions server.

This is the base of the gateway server:

import { ApolloServer } from "@apollo/server";
import { ApolloGateway } from "@apollo/gateway";
import { createServer } from "http";
import express from "express";
import { createServer as createProxy } from "http-proxy";

const proxy = createProxy({
  target: "ws://localhost:4002/subscriptions",
  ws: true,
  changeOrigin: true,
});

const app = express();
const httpServer = createServer(app);

const supergraphSdl = new IntrospectAndCompose({
  subgraphs: [
    {
      name: "gql",
      url: "http://localhost:4001/graphql",
    },
    {
      name: "sub",
      url: "http://localhost:4002/graphql",
    },
  ],
});

const gateway = new ApolloGateway({
  supergraphSdl,
});

const server = new ApolloServer({
  gateway,
});

httpServer.on("upgrade", (req, socket, head) => {
  proxy.ws(req, socket, head);
});

httpServer.listen(4000, () => {
  console.log(`🚀 Server ready at http://localhost:4000/graphql`);
});