Performance expectations—1.5-2% CPU usage reasonable?

[joshcbrown]

Hi there!

I'm building a small app for a pomodoro timer and task management. The app currently looks like this:

When the timer is running, I redraw the app (minus the stats widget which I cache) four times every second and CPU usage sits at about 1.5-2% (idle, it sits at 0% as you'd hope). This isn't enough to make a noticeable impact elsewhere on the system, but just curious whether this is what you'd expect?

A previous project that I wrote in Rust consumes almost nothing while active. I wouldn't think the language/library should make that much of a difference given that the vast majority of the time, the app's sleeping.
I did some profiling to confirm this:

Over 99% of the time is idle. I note also that the second-most time-consuming activity is GC. Maybe the extra overhead is mostly from that? If you like, you can view this graph at speedscope with this JSON.

I won't ask you to read the code, but if you'd like to, it's available here.

Thanks very much in advance, and thanks for building such a fun library to work with! Appreciate your work.

[jtdaugherty]

Hi @joshcbrown, thanks for doing a bunch of legwork to dig into this.

As for what to expect, I can't say; what you're seeing doesn't seem outrageous to me, but it's possible it could be reduced somewhat. I ran Brick's brick-custom-event-demo at a tick rate of 0.25s and it draws practically nothing, but its CPU usage on my system was 0.7%. That tells me that some of the GC overhead you're seeing is likely Brick's rendering loop and Vty rather than your application. I haven't done profiling on that in a long time so I don't know where garbage is being generated. The rendering loop (i.e. the Widget type) is a state computation, the output of which gets partially thrown away between redraws, and the orchestration to run that computation and draw the screen could also be a source of garbage.

In general, I would definitely not expect runtime behavior of Haskell to match Rust. Rust is definitely going to be leaner due to it not having GC and having a comparatively very lightweight runtime system. Plus, there are a ton of libraries involved in a Brick application that make an apples-to-apples comparison impossible.

Also, since I did want to take a look at your source to see what might be going on, I noticed a few things. In UI.hs, there are lots of uses of zoom for granular actions like:

zoom ts $ handleTaskEvent (DeleteAt i)
zoom ts $ handleTaskEvent (InsertAt i task)

These can be bundled up as follows:

zoom ts $ do
    handleTaskEvent (DeleteAt i)
    handleTaskEvent (InsertAt i task)

(or factored out of case arms, etc.)

For now I guess I'd say the behavior you're seeing is what I'd expect, but expectations are subjective. I'm happy to leave this open as a reminder to do some profiling on Brick to see if the GC overhead can be reduced.

[jtdaugherty]

According to that profile, most of the time and allocation is coming from Brick and Vty, which I would expect if the application isn't doing much other than updating a bit of its state and generating new UI frames. All but three of those top listed cost centers are part of rendering the UI.

[jtdaugherty]

I'd have to look at your widget constructions more closely to know for sure, but one possibility is that the composition of the UI (the structure of the Widget computation) matters. While I would expect frame generation to result in lots of allocation, I'm a little surprised at the breakdown. The fact that cropResultToContext in particular is high up on the list makes me wonder if the UI is made up of lots of very tiny widgets. If that's the case, it's quite possible some gains could be gotten by constructing some Vty images directly instead of, say, using hBoxes or vBoxes made up of lots of tiny elements.

[jtdaugherty]

Looking at statsW, that might be the case: there are lots of 1-cell widgets and clickable extents being recorded, which would give cropResultToContext a lot more work to do. One way around this, which would reduce that overhead, would be to:

1. Convert statsW to a single custom widget (or a vBox of custom widgets) that build up a Vty image and render it with Brick.Widgets.Core.raw instead of building up a large box of many individually-clickable cells.
2. Handle mouse events in a single extent for the entire stats widget, and map click coordinates to the day cell you want rather than requesting a clickable extent to be recorded for each individual cell.

[joshcbrown]

Thanks! Doing the naive conversion of the code I had to generating a Vty image and handling mouse events for the whole widget has made a big difference.

I thought this wouldn't matter because I was caching the stats widget but I'm guessing that you still perform the rendering pipeline on cached widgets each loop.

Really appreciate your help, I'm definitely comfortable now with the perf.

[jtdaugherty]

Thanks! Doing the naive conversion of the code I had to generating a Vty image and handling mouse events for the whole widget has made a big difference.

I'm glad to hear it!

I thought this wouldn't matter because I was caching the stats widget but I'm guessing that you still perform the rendering pipeline on cached widgets each loop.

That's right; the image gets cached, but so do other bits of rendering metadata like extents, and those get re-processed by parent widgets' calls to cropResultToContext since the layout can change even if the cached widget doesn't.