[perf] Boost 1.5.2 got a hickup (compared to 1.5.1)

[ibrainventures]

Describe the bug

Many x-thousand thanks for the performance boosting in the last 3 upgrades!

After upgrading from 1.5.1 to 1.5.2 we got a sporadic performance-issue on "bootup"
the compiled app.

Normaly our Lighthouse Timemeasures for FMP / FCP are stable around 0.6 - 0.8 s.
After Upgrading to 1.5.2 the peak are often on 1.3 seconds. Reverting to 1.5.1 we didnt
get those peaks.

May the screen-size body injection / timeslot makes here some trouble? All other
changes may are are not global effective?

Chrome 78.0.3904.108 64 Bit
Windows 10

No 3rd Party Packages, no API call during the measuring. Inhouse Network, no public i-net.

If there is no recap about this issue possible, may this is only for the records / keep-in-mind if
others have some same effects.

Many thanks for all your work.

[ibrainventures]

Some thinking / reasons:
We are using also some mediaqueries around the qlayout with other breakpoints.
May this interfere during the boot-up / Dom creation / quasar screen calculation / injection.

If this is a edge case, is it possible to "swtich" of that body injection easily (not with own fork, to stay inside the upgrade-flow ..) ?

[pdanpdan]

Can you please try with these test builds?

1. "quasar": "pdanpdan/quasar#quasar-v1.5.2-test.1-gitpkg" - this one has the body class adding/removing disabled
2. "quasar": "pdanpdan/quasar#quasar-v1.5.2-test.2-gitpkg" - this one is the normal build (it's from my branch so please test against this one so we can only compare the speed changes introduced by class adding)

[ibrainventures]

Hi @pdanpdan,

thanks for taking this issue. Strange. i tested now all 4 Versions, around 200+ times:

1.5.1 - hardnailed
1.5.2 - official git
1.5.2-test-1
1.5.2-test-2

1.5.1 : allways 0.6 - 0.9 Lighthouse FMP - never can provocate to go higher than 0.9

all 3 other editions, are stable more than 1 .. never can provocate to go lower than 1

crazy .. cant understand this world : (1.5.2-test-1 should be like 1.5.1 , but it is more 1.5.2)

[pdanpdan]

Can you please test this one: "quasar": "pdanpdan/quasar#quasar-v1.5.2-test.3-gitpkg" - it has all changes in screen reverted.

[ibrainventures]

first start .. not only measurable, also subjectiv in render-speed-inside the browser:

[ibrainventures]

so its again .. "raketenschnell" :-)

[pdanpdan]

So with test.3 is back on the performance of 1.5.1?

[ibrainventures]

yes ! ..

[rstoenescu]

@ibrainventures Can you ping me on Discord pls? Want to speed this up.

[rstoenescu]

Fix available in "quasar" v1.5.3.

[ibrainventures]

@pdanpdan @rstoenescu
thank you for the ticket takeover.

Tested 100+ times with the 1.5.3 edition and no peaks! Absolute stable at 0.8-0.9 seconds.

Never saw the 1.+ again! .Also made some crosstesting with the older 1.5.2 (offical git) and
there was the hickup back. So this issue-fix / optional feature is (also with some mediaqueries and centered drawer-layout, css-root-var-mediaquery-manip/calc-ulation and some more "dirty things" ;-) ) perfect.

Back to lightspeed!
Happy day-after-1st-Advent. And many thanks for the quasar.

[robert-niestroj]

I dont know how you detect these classes but i see that you are not using https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia . Have you considered it?

[ibrainventures]

hi @robert-niestroj

i think your question was for the quasar-team ... i think they are going over the underlaying media-breakpoints against the actuat screen-size ..

i tried some weeks ago the matchMedia methods and i given up. The problem was the iOS/ IpadOs Safari with the Landscape / Portrait Rotation. After one Rotation i got no "right" mediaqueries after that event. (that seems to be a known issue, since x-years ...) .. i stopped after some hours and gone by mediaquery / altering a css root var. No problem since then ..