Freeze without any visual feedback when switching Circle

When I switch from one Circle to another one, I get between 3s and 6s of freeze without any visual feedback.

The very minimum would be to display a loader, even though 6s loader + chat history loading afterwards wouldn't be acceptable either. On top of that, I do not think we can propose that because the menu is not updated yet at that moment, and the whole app stops responding during the freeze, so I'm not sure we are even able to trigger a loader.

I guess that leads us with the only viable option, which is to remove this lag. All the eyes turn to @matthieu and @balessan. I'm available to help testing as much as necessary. I can't push the app in that state to our users, they will think we are unable to build anything correctly and that our app will always be shitty. They have to think that interoperability can work, otherwise we won't sell it.

changed milestone to %Previously done stuff

By Alexandre on 2020-02-24T21:59:24 (imported from GitLab project)

added 1 deleted label

added 1 deleted label

@alexandre @jbpasquier : do you have any idea about the source of this freeze ?

I mean, just saying it lags won't help us either, and I could answer that's it xmpp or whatever I wish.

Did you check if it could come from the server ? A default performance check from your inspector would help :-)

I myself have no idea. I let you guys dig deeper and enlighten us. That being said it comes from the framework almost for sure, as the router is not even switching route during the freeze. I can't see how that could be related to XMPP, but I haven't validated that intuition, it just seemed obvious to me.

By Alexandre on 2020-02-28T06:29:29 (imported from GitLab project)

I already tested it but I didn't found anything. I'll dig deeper.
It's not easy to reproduce as for me, it's a lot faster:

Funny. Should you try with my account maybe? I send you the credentials on Whatsapp.

On which browser are you testing?

By Alexandre on 2020-02-28T07:56:25 (imported from GitLab project)

It's globally a bit slower with your account, and I think it's a bit slower in Firefox too.

I think the problem comes from these lines: https://git.happy-dev.fr/startinblox/framework/sib-core/blob/master/src/components/sib-display.ts#L34-44

Each time we click on a menu item, all the sib-displays on the page react to the navigate event (including the children of sib-displays, which are also sib-displays).

At this moment, we also add the data-src of many sib-displays of the circle page. It means we are creating hundreds of children sib-display, each of them registering a new event.

We finish having thousands of sib-displays reacting on each navigate event.

When I comment these lines, it seems faster to me (but we don't have the active on menus anymore)

@balessan @clement what do you think?

Well done to have spotted that one. I think this is one of the biggest pain in the app at the moment.

By Alexandre on 2020-02-28T09:03:02 (imported from GitLab project)

mentioned in issue #417 (closed)

By Alexandre on 2020-03-06T10:40:52 (imported from GitLab project)

In @matthieu hands to test a similar approach as for the sib-badge for the management of the active class and see if that helps.

I've been testing more and I'm not sure anymore it comes from the navigate events. (at least not only from it)

What I can see is that after switching between menu items a lot, even if you wait for a while, each time you click one menu item again, it is much slower than at the beginning.

It happens only for circles (not 1-1 conversations), and when the whole circle-informations page is removed, the problem disappears. Removing only the form of only the display of the circle is not enough. So it seems the problem comes from the rendering of the whole content when an circle is clicked. I'm not sure where exactly and how to fix this...

Very interesting feedback. Thank you @matthieu.

What could be a smart next step here? Have you tested all you could? Maybe planning a peer-debugging session with @jbpasquier might help pinning down the problem?

By Alexandre on 2020-03-12T17:35:30 (imported from GitLab project)

@jbpasquier @alexandre : won't be enough (we need to fix performance anyway) but in the meantime if looks feasible to me to add a full page loader using an event listener on the navigate event, filtering the appearance and disappearance of this loader only for the circle associated routes.

@matthieu: Could we trace which events are triggered when switching between circles ? Could we time several repetitions of that switch between circles to see what's time degradation we are talking about exactly ?

Having a loader would indeed help. The whole app freezes. You have to trigger it before it does, I guess you know that :-)

By Alexandre on 2020-03-12T19:08:28 (imported from GitLab project)

Are you sure it is a freeze or something you don't see is processing ?

He he, that's what I would call a freeze :-)

I'm not sure what you are asking.

By Alexandre on 2020-03-14T07:56:05 (imported from GitLab project)

I made some changes in sib-core on the branch bugfix/594-performance-improvements. All the related discussions are available here: framework/sib-core#594 (closed)

It still needs to be tested with some apps to make sure it does not break anything.

mentioned in issue management/core-team#2

changed milestone to %Performance part I

mentioned in issue framework/sib-core#611 (closed)

To recap the discussion we had with @sylvain yesterday, we identified at least 3 issues in the core linked to this one:

1. the sib-displays are all listening to the navigate event. We should use PubSub instead (framework/sib-core#611 (closed))
2. Every new rendering of a component is added at the end of the Javascript queue. It means that if we click on 5 circles quickly, the 5 will need to render in that order, which is very long. (framework/sib-core#594 (closed))
3. Once a render starts, it cannot be cancelled

The 2 and 3 are very linked, and probably need a deeper investigation, on how to build a rendering system which allows all of that (framework/sib-core#286 (closed)).

@balessan I think we need to talk this new rendering system :)

mentioned in issue framework/sib-core#594 (closed)

So as part of the new rendering system will come with Core 0.11 I'm closing this one. We will reopen with specific issues if needed. This one starts to be a bit old to follow closely problems.

closed