Investigate allocations in Fact.toEvent: allocates a Pair for each comparison

[mcomella]

Fact.toEvent uses a when statement with 36 items to compare its value. For each value, it's comparing to a Pair:

    private fun Fact.toEvent(): Event? = when (Pair(component, item)) {
        Component.FEATURE_PROMPTS to LoginDialogFacts.Items.DISPLAY -> Event.LoginDialogPromptDisplayed
        Component.FEATURE_PROMPTS to LoginDialogFacts.Items.CANCEL -> Event.LoginDialogPromptCancelled
        ...

The to function is actually allocating a Pair for each item, each time this is called (i.e. we may allocate 35 times in the current code). It doesn't get optimized out: here's the bytecode for the first comparison:

   L4
    LINENUMBER 161 L4
    ALOAD 2
    GETSTATIC mozilla/components/support/base/Component.FEATURE_PROMPTS : Lmozilla/components/support/base/Component;
    LDC "display"
    INVOKESTATIC kotlin/TuplesKt.to (Ljava/lang/Object;Ljava/lang/Object;)Lkotlin/Pair;
    INVOKESTATIC kotlin/jvm/internal/Intrinsics.areEqual (Ljava/lang/Object;Ljava/lang/Object;)Z
    IFEQ L5
   L6
    GETSTATIC org/mozilla/fenix/components/metrics/Event$LoginDialogPromptDisplayed.INSTANCE : Lorg/mozilla/fenix/components/metrics/Event$LoginDialogPromptDisplayed;
    CHECKCAST org/mozilla/fenix/components/metrics/Event
    GOTO L7

It's unclear how bad this is in practice: e.g. what the duration is for being called once, how many times it may be called in a row, if it's blocking the main thread, and if 35 Pairs (4.4 KiB?) will create a lot of churn in the GC.

┆Issue is synchronized with this Jira Task

[mcomella]

This code is wrapped by the MetricController.track function and will eventually go through the even larger switch statement:

This might be a good opportunity to measure that too as this will also execute synchronously and could block the following code.

Question: is taking a profile good enough to understand this code or should we benchmark?

[mcomella]

In browsing around the app, I subjectively noticed that Fact.toEvent returns null in most cases so we're hitting the worst case in most cases. It's unclear what the granularity of the clock is but once the code is jitted, it's anywhere from 0.21ms (it might be lower because it might be hitting clock granularity) to 1.14ms per Fact.toEvent call.

In the case of the awesomebar providers, each keystroke triggers 7 facts, which is 1.75ms summed in the best case (caveat: clock granularity) and 2.64ms in one case where I measured each call individually (caveat still applies). This isn't a user perceptible delay so I'm more concerned about this from a battery and memory perspective.

This code is wrapped by the MetricController.track function and will eventually go through the even larger switch statement:

In 13 iterations of the track block, a median run through it is 0.66ms with the max as 1.09ms and min as 0.36ms (i.e. this doesn't seem to hit clock granularity). This seems to get called roughly as often as Fact.toEvent so I'm also concerned about this from a battery perspective but not duration.

Then again we have no idea how much battery these use beyond "less work is better for battery" so it's difficult to measure the power use impact. However, they seem like relatively straight forward fixes so it might be worth it for a blind fix.

[mcomella]

wrt allocations, typing in the awesomebar produces a sin wave pattern:

In the first screenshot, I typed "no no im figuring it out" and the memory went from ~144.3 MB to 167.6 MB and back down to 144.4 MB, and it continues to climb afterwards. This may not be directly related to the Fact.toEvent calls. In general, memory usage appears to increase the longer the awesome screen is open with a GC maybe every 20s, even if I'm not typing anything:

Summary

There are three issues in this bug:

• Fact.toEvent excessive allocations, suspected power use. Filed Fact.toEvent is called many times & generally allocates 35 Pairs each time: power use issue #21294
• track suspected power use. Filed MetricController.track & Event.wrapper may use non-trivial power: called frequently #21292
• memory usage gradually increases on awesomescreen even without user interaction (I didn't check if this actually happens outside the screen too & the scale was too large to get specific measurements but the Java memory was 74.5 MB before I opened the awesomescreen and 182.9 MB when I stopped recording) edit: see comment below
• investigate 0.2-0.3 MB allocation per keystroke: what's allocated? Can we do better? (see below) 1MB per 5 characters seems like a lot. Filed 0.2-0.3 MiB allocated per keystroke on awesomescreen #21293

I'm guessing we should file these separately? They seem like they could be good help wanted tickets. I'll wait for triage to decide.

[mcomella]

and it continues to climb afterwards. This may not be directly related to the Fact.toEvent calls. In general, memory usage appears to increase the longer the awesome screen is open with a GC maybe every 20s, even if I'm not typing anything:

I discovered the gradual increase was because the Gecko profiler was sampling because I accidentally left the profiler file in.

However, without the gradual allocations, I was able to determine each keystroke allocates 0.2-0.3 MB of memory.

[mcomella]

To make the issues easier to understand, I changed this issue to an investigation issue and filed 3 follow-ups linked from #21171 (comment)