Score generation and header colorization

[b-winkler]

Hi Ramon!

I did not find any description on how the score (1 to 5, I guess) is calculated.
Seems to be either based on the maximum time or the accumulated compile times. The former would make sense, in a way, the latter would not help much for local optimization.
Could you provide a short explanation, please?

Cheers, Benni

[Viladoman]

Good point. I should add more info about that in the wiki.

The score is called in code 'severity' and it is computed on .scor load here.

It is currently using the maximum time value. The score itself, by default, is normalized. This means that all includes are split equally in 5 different buckets ( 0%-20% | 20% - 40% .... ). Example: An include file that has score 5/5 means that it falls in the 20% of most expensive includes in the solution. In Tools / Options / CompileScore you can change the thresholds to global values instead of normalized.

Those settings are not in the Extensions / CompileScore / Options because they are user specific instead of data specific imho.

Are there any metrics that you think would be beneficial to add in there?

[b-winkler]

Hi Ramon,

sorry for the late reply and thank you for the explanation.

The bucket approach absolutely makes sense if you do not know where you stand, I like the idea.

We optimized our build times lately using C++ Build Insights, and of course every metric has its benefits. Mostly, we used inclusive and exclusive build times to find and optimize expensive headers. This is something you do not explicitly calculate, if I am correct (and that is totally fine).
But in my opinion (or at least in our case) the maximum time is not especially well suited, because it will disregard multiple inclusions.
For instance, <string> is in our top list. But since it will be (indirectly) included in almost every header, we can hardly optimize it away.

So if you ask me, I would go with average time as a starter.

And regarding the buckets thresholds: I just did a rough estimate and we have approx 3500 direct includes in our projects. However, due to indirect includes in our libraries CompileScore lists more than 10000. Most of them are negligible and end up in the buckets with the fastest includes. So basically, the 1 and 2 score buckets hardly show up in my example and we end up with only 3 significant buckets.
So in our example it would probably make sense to concentrate on the top 2% or 5% first. Which would require to be able to change the normalization factors.
Maybe that would be possible (adding an option for that)?

Cheers, Benni

PS: Accidentally sent the comment before it was finished.
Just wanted to add: Great extension and I want my team to be using it in order to keep build times low!!

[Viladoman]

Thanks for the feedback. It is super useful to understand the real needs of other coders and codebases. Everything you exposed makes total sense!

To be honest I think that each of the attributes ( accumulated, max, min, avg, count ) are valuable so it might be worth having some extra settings to choose the one used for the coloring buckets. Also being able to change the bucket normalized thresholds is a brilliant idea. As you mentioned the most probable outcome in real big production codebases is to never see the small includes.

I agree that having more customization on the text highlight can be beneficial.

My only doubt would be if those settings are something that should go in the CompileScoreSettings.json ( Extensions / CompileScore / Settings ) as whole project settings and shared between all programmers or more of a per user visualization configuration ( Tools / Options / CompileScore ), like disabling text highlights ( shared across all projects for the given user ).

[b-winkler]

Having settings for the score attribute is a great idea. I just did not want to ask for too much ;-)
In our case shared settings might be beneficial but not crucial. After all, I think these settings would not be changed too often.

[Viladoman]

Finally in version 1.5.7, I added under Tool/Options/CompileScore (per user settings):

• The option to set the Severity Criteria ( Min, Max, Average... )
• The option to define the severity percentages for the normalize method.

I hope this will help improve the readability and analysis. Let me know further improvements. I think this additions are super valuable.

Thanks!