# Profiling techniques for GUI code

**URL:** https://forum.juce.com/t/profiling-techniques-for-gui-code/45235
**Category:** General JUCE discussion
**Created:** [March 26, 2021, 2:57pm UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235 "2021-03-26T14:57:42Z")
**Posts on this page:** 11
**Page:** 1

<div class="post-metadata">

### Author: ![mqtthiqs](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mqtthiqs/32/14729_2.png) [@mqtthiqs](https://forum.juce.com/u/mqtthiqs)
#### Post date: [March 26, 2021, 2:57pm UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/1 "2021-03-26T14:57:42Z")

</div>

Hello,

I am developing a few UI Components for simple data visualisation (scopes, FFT etc.); as they are constantly redrawn performance is important and I’m looking for ways to profile various metrics. XCode’s Instrument is my tool of choice for the moment but I find it a bit cumbersome and not so informative. Plus, I’m willing to instrument my code.

Just OTOH here are a few pieces of info I’d be looking for :

- global pressure on the GUI thread + dropped frames
- local (one component) and cumulative (+ all children) :
  - paint time average
  - paint time variance/max (are some frames more expensive to compute than others?)
  - average `paint()` and `repaint()` frequency

My questions:

1. What are the general techniques people use to profile and optimize UI code?
2. Which JUCE functions are entry points to time paints? For instance, is all the (local) painting work done synchronously in the `paint()` method?
3. Any tool, metrics or concepts I might have missed?

Thanks in advance!

---

<div class="post-metadata">

### Author: ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)
#### Post date: [March 26, 2021, 9:57pm UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/2 "2021-03-26T21:57:59Z")

</div>

> [@mqtthiqs](#):
>
> 1. Which JUCE functions are entry points to time paints? For instance, is all the (local) painting work done synchronously in the paint() method?

All of the drawing code for your custom Components will come from your overridden `paint()` method (and `paintOverChildren()`) so if you need to calculate the time it takes to draw your component you can just get the start and end times at the top and bottom of your `paint()` method.

A few tips and tricks I’ve picked up over the years are:

1. Only redraw what needs to be redrawn. IE if you have a static background, don’t be drawing it every frame along with your dynamic content.
2. Draw text as little as often. Text rendering is expensive.
3. If your component is static and takes longer to draw than drawing an image of the same size, call `setBufferedToImage()` on it so it only gets repainted when it needs to.
4. If a Component has children, don’t do any painting in it. Backgrounds for example should be drawn in dedicated Components, not in a component that has other components as children, especially if those child components are expensive to draw.
5. Don’t worry about performance that much. If your priority is to make a good product to be able to sell, just get your performance to be good enough and move onto other features. Unless you have a large team, it’s not worth the time it’ll take to highly optimise your entire GUI.

I’ve only ever used Visual Studio’s built in profiler for profiling GUI code so I’m afraid I can’t offer any advise on your other 2 questions.

---

<div class="post-metadata">

### Author: ![mqtthiqs](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mqtthiqs/32/14729_2.png) [@mqtthiqs](https://forum.juce.com/u/mqtthiqs)
#### Post date: [March 27, 2021, 9:44am UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/3 "2021-03-27T09:44:22Z")

</div>

Thanks, this helps @ImJimmi. I had seen and implemented these advices, except for 4.

> If a Component has children, don’t do any painting in it.

Could you develop a bit? I could imagine the rationale behind it being that `paint()` of a child component doesn’t happen every time the parent is `paint()`ed, (so the background’s `paint()` could be avoided) but I’m not sure exactly _when_ that happens.

---

<div class="post-metadata">

### Author: ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)
#### Post date: [March 27, 2021, 10:48am UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/4 "2021-03-27T10:48:52Z")

</div>

It’s to do with the previous point about `setBufferedToImage()`…

In short, if you call `setBufferedToImage()` on a Component, its `paint()` method will only get called if that Component is flagged as needing to be repainted (IE if you call `repaint()` on it), otherwise JUCE will draw the buffered image instead which may improve performace.

However, if the Component you call `setBufferedToImage()` on has a child component that is constantly redrawing, it will also invalidate the parent Component meaning even though nothing has changed in your parent, it will still have its `paint()` method called regularly.

If instead you put that drawing code in a dedicated Component and call `setBufferedToImage()` on it, it won’t be invalidated when its _sibling_ is redrawn and the parent Component won’t have any drawing code so it won’t matter that it’s constantly being redrawn.

It’s not needed _all_ the time, but it’s a good habit to get into IMO.

---

<div class="post-metadata">

### Author: ![lalala](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/lalala/32/8577_2.png) [@lalala](https://forum.juce.com/u/lalala)
#### Post date: [March 27, 2021, 11:12am UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/5 "2021-03-27T11:12:33Z")

</div>

be sure to call `setOpaque (true);` on the opaque components also.

---

<div class="post-metadata">

### Author: ![mqtthiqs](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mqtthiqs/32/14729_2.png) [@mqtthiqs](https://forum.juce.com/u/mqtthiqs)
#### Post date: [March 29, 2021, 7:41am UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/6 "2021-03-29T07:41:27Z")

</div>

Thanks @ImJimmi, it makes sense; @lalala yes I’m aware of that, thanks anyways.  
That said I was more asking for _profiling_ techniques, not _optimization_ ones. I might just roll my own if nothing already exists.

---

<div class="post-metadata">

### Author: ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)
#### Post date: [March 29, 2021, 8:14am UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/7 "2021-03-29T08:14:16Z")

</div>

> [@mqtthiqs](#):
>
> I was more asking for _profiling_ techniques

The most important thing is to simply figure out which of your processes is taking up a significant chunk of time, which is something pretty much any basic profiler can do. I believe Xcode has Instruments which is a collection of profiling utilities but I’ve never used them myself - I’ve only ever used the built in profiler in Visual Studio on Windows.

They’ll usually point you to some low-level function that’s being called over and over again, taking up a lot of time so you just need to look up through the callstack to find where in your own code it’s being called. A flamegraph can help with that because it shows the callstack in a more visual way where it’s usually easier to see processes that are taking a long time.

---

<div class="post-metadata">

### Author: ![jpo](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jpo/32/503_2.png) [@jpo](https://forum.juce.com/u/jpo)
#### Post date: [March 29, 2021, 9:02am UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/8 "2021-03-29T09:02:43Z")

</div>

This is something I have used when trying to improve the perf of my gui:

> [@Displaying statistics about the components that take the most time to paint](https://forum.juce.com/t/displaying-statistics-about-the-components-that-take-the-most-time-to-paint/35536):
>
> Here is a small patch to juce that displays the list of components that are being repainted, with their name, class name, duration of the last paint(). Here is an example of it output: TopLevelComponent: MyApp t=0.0282652 getClipBounds=0 0 1023 1123 0 0.028265s 100.0% 4.002453s (self: 1.0% 0.041799s) "MyApp" class StandaloneGUI sz=1023x1123 1 0.000142s 3.9% 0.155630s (self: 3.9% 0.155630s) "" class juce::MenuBarComponent sz=1021x31 1 0.028028s 95.1% 3.805024s (self: 0.1% 0.00547…

---

<div class="post-metadata">

### Author: ![mqtthiqs](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mqtthiqs/32/14729_2.png) [@mqtthiqs](https://forum.juce.com/u/mqtthiqs)
#### Post date: [March 29, 2021, 9:15am UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/9 "2021-03-29T09:15:15Z")

</div>

@jpo that’s exactly what I was looking for!  
Thanks a bunch!

---

<div class="post-metadata">

### Author: ![connorreviere](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/connorreviere/32/4890_2.png) [@connorreviere](https://forum.juce.com/u/connorreviere)
#### Post date: [March 29, 2021, 4:11pm UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/10 "2021-03-29T16:11:46Z")

</div>

In case you haven’t come across it, there’s also the `JUCE_ENABLE_REPAINT_DEBUGGING` config option that will let you see which components are being repainted visually.

---

<div class="post-metadata">

### Author: ![cackland](https://avatars.discourse-cdn.com/v4/letter/c/9de0a6/32.png) [@cackland](https://forum.juce.com/u/cackland)
#### Post date: [March 29, 2021, 10:27pm UTC](https://forum.juce.com/t/profiling-techniques-for-gui-code/45235/11 "2021-03-29T22:27:02Z")

</div>

I’ve looked in the following file path:

juce\_gui\_basics/components/juce\_Component.cpp.

And couldn’t find that debugging information.
