luke.b//blog

I’ve made a load of progress on the photo blog format!

I still find it so cool that Hugo enables so many use-cases without breaking a sweat.

I’ve reused the majority of the short blog format (“log”) to create a fairly simple “single” view for a bundle of photos.

Each photo blog will contain several photos and a single markdown file that includes the content for that post.

The photos are shown inline in the post, but when clicked/focussed, they rearrange into a very basic image viewer implemented entirely in CSS (using :focus, :hover, :focus-within and more).

I didn’t find time to upload the photos I took today, but I wrote a post about some photos I took when I went to Edinburgh that I’ll put up tomorrow hopefully.

I’ve got 25mins to make a photo blog. Let’s do this thing.

Made some more progress on nomad performance, but have introduced some regressions with wrapping. Time to fix some bugs and write some tests! But not now, maybe tomorrow.

Also tomorrow: photo blog.

After generating many many flame graphs, I’ve discovered a few reasons why nomad isn’t performing as well as it could be. Most of the optimisations to be had for the use cases I care about are to do with preventing unnecessary re-rendering of lines that have been rendered previously.

At the moment, nomad will re-draw N lines of the subterminal without caching the result. This means it will have to apply the formatting to every line for every tiny change, even when the cursor position updates!

I think one improvement could be to apply formats to lines when they change and store the formatted line in memory ready to be drawn later. This could require wrapping of formatted lines, which isn’t impossible but could be very tricky to get right.

Ooof. This is a late one.

I worked for a few hours trying to increase nomad performance, and I had a few small successes and realisations so it’s already improved a bit.

Scrolling up and down in vim definitely feels closer to how it it feels on Terminal.app, which is a great sign.

I think I need a way to test performance as I use nomad. I found https://clinicjs.org/ which is pretty damn cool, but it won’t let me test something that hooks into a TTY. Maybe I’ll send them a PR?

Should probably sleep first though.

I’ve changed the control sequence parsing function to not be recursive, which has lead to a big performance increase.

I’m not exactly sure how big but in some cases, it could be equivalent to x4 speed up.

From some flamegraph profiling, I can see that getCtlSeqs performs quite poorly in comparison to the rest of nomad.

What I want to do next is create a load test that measures the performance of this function so that I can try improving it in isolation from the rest of the app.

Fixed a bug with nomad where a viewport smaller than the buffer would render the top “h” lines of the buffer instead of the last “h” lines, where “h” is viewport height.

I love rainy days because I don’t have to feel guilty about staying inside all day and coding :D

Oh and I want to see if I can make some performance improvements or at least some performance tooling for nomad.