[Performance] Blaze rendering abnormally slow on large DOM changes from infinite scroll (iPhone)

mobile
1

I’m running into performance issue with infinite loading on mobile (iPhone). Anyone with experience? Using session variable as limit for subscription. Initial loading of 200 items loads almost instantly (<1s).
Increasing session var to increase limit (30 increments) however, the UI chokes, rendering 3-5 item chunks at a time for 20s+ until the 30 is done loading.

I’ve tried debugging if it’s any post processing on rendering I do that’s causing it but it’s not noticeable enough for the large difference in rendering speed. Especially since all items are rendered equally and first 200 loads fast, not subsequently. And the thing is this speed difference is only on mobile, on Chrome desktop there’s little slow down in subsequent loading.

My app is running latest Meteor (1.0.3.2). My impression for the drastic slowdown is on initial load, 200 items come in at once and gets rendered together. On subsequent items coming into the subscription, items are loading through the network and rendered piecemeal, and choking. I also use the fastRender package, but I’ve tried disabling that and makes no difference on performance described above.

If you like to take a look if this is indeed a Blaze performance issue with mobile Safari/Chrome (instead of my stupidity I’m not seeing after some hair pulling), please go to http://clubch.at/. Console outputs logs of “msg ()”, only the timestamp is of interest for each time a new item is “seen” in a Messages.find().observeChanges // added and rendered.

2

Please post your code and provide a repo with the minimum repro.

3

Ok. A bit hard to be minimal with reproducing this but I’ll look at ripping it out of my app.

I should also add that I’m using Iron Router, with 2 subscriptions to the the same Messages collection published: 1 is inside a waitOn with static limit variable to the subscription, 2 is in a onBeforeAction with a Session reactive var as limit to the subscription. Rendering blocks on waitOn on initial data loading until the 1st subscription is done, but not on subsequent loading that has 2nd subscription limit reactively raised. Is that a reason for the poor performance on subsequent load? The 2nd subscription is because the 1st sub params in waitOn, if not static, would re-render the whole route on change to sub params.

This seem to be a fairly common pattern for doing infinite pagination. And the performance is fine on desktop browser, it’s just choking on mobile.

4

I’ve done more investigations and did a workaround. Or a hack, if direct minimongo manipulation is that. See https://github.com/meteor/meteor/issues/3976. Thoughts welcome.

1 Like
5

Might be related to “Infinite loop when manipulating large DOM set”?

6

Not sure. In my case nothing reloads, at least not repeatable. I have seen app reload suddenly but I think it’s due to OOM (memory) from minimongo storing too much data.