[Profiling] Adding normalize by time and scale factor on Diff TopN functions page

[cauemarcondes]

Relevant changes:

• Adding Normalize by field on the Diff TopN functions page.
• Refactoring functions route/pages.

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[cauemarcondes]

Question: I'm not sure if I should scale the CPU values too! @elastic/profiling-ui does anybody know it?

[jbcrail]

My understanding is that scaling the CPU values would require scaling both the numerator and denominator, which would cancel out the scaling factor when dividing. So I don't believe it's necessary.

[jbcrail]

To show my work and prove it to myself also, here's my reasoning:

• All definitions apply equally to the inclusive and exclusive CPU values.
• We'll assume inclusive without loss of generality for any CPU_n and Total_n.
• CPU₁ is the baseline CPU
• CPU₂ is the comparison CPU
• Total₁ is the baseline total count
• Total₂ is the comparison total count
• SF₁ is the baseline scaling factor
• SF₂ is the comparison scaling factor

Without scaling

CPU_diff = 100 * (CPU₁ / Total₁) - 100 * (CPU₂ / Total₂)

or

CPU_diff = 100 * [(CPU₁ / Total₁) - (CPU₂ / Total₂)]

With scaling

CPU_diff = 100 * [(SF₁* CPU₁) / (SF₁ * Total₁)] - 100 * [(SF₂ * CPU₂) / (SF₂ * Total₂)]

or this after cancellation:

CPU_diff = 100 * (CPU₁ / Total₁) - 100 * (CPU₂ / Total₂)

which is the same as without scaling.

[cauemarcondes]

TIL
wow, great explanation! thank you! 🤓

[cauemarcondes]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: dd9aed7

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
profiling	152	154	+2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
profiling	288.6KB	290.4KB	+1.8KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
profiling	14.7KB	14.4KB	-292.0B

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
securitySolution	410	414	+4
total			+6

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
securitySolution	491	495	+4
total			+6

History

• 💚 Build #134360 succeeded 3593f54
• 💔 Build #134229 failed 93c9885
• 💔 Build #134011 failed c6e840d

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[jbcrail]

Looks good to me.

I answered your question about whether we need to scale the CPU values.

[jbcrail]

My understanding is that scaling the CPU values would require scaling both the numerator and denominator, which would cancel out the scaling factor when dividing. So I don't believe it's necessary.

[jbcrail]

To show my work and prove it to myself also, here's my reasoning:

• All definitions apply equally to the inclusive and exclusive CPU values.
• We'll assume inclusive without loss of generality for any CPU_n and Total_n.
• CPU₁ is the baseline CPU
• CPU₂ is the comparison CPU
• Total₁ is the baseline total count
• Total₂ is the comparison total count
• SF₁ is the baseline scaling factor
• SF₂ is the comparison scaling factor

Without scaling

CPU_diff = 100 * (CPU₁ / Total₁) - 100 * (CPU₂ / Total₂)

or

CPU_diff = 100 * [(CPU₁ / Total₁) - (CPU₂ / Total₂)]

With scaling

CPU_diff = 100 * [(SF₁* CPU₁) / (SF₁ * Total₁)] - 100 * [(SF₂ * CPU₂) / (SF₂ * Total₂)]

or this after cancellation:

CPU_diff = 100 * (CPU₁ / Total₁) - 100 * (CPU₂ / Total₂)

which is the same as without scaling.