[Staging] Perfomance issues

This is a pressing issue, as we unfortunately can't allowed ourselves anymore to have performance issues. We have been waiting for months to have LDFlex, and it is still very slow. I don't know what needs fixing on the framework's side but it still feels like we are back to the 90s when using Statin'blox, and the fan of my laptop is screaming every time I touch the app.

To reproduce on https://test-paris.happy-dev.fr/:

• Click on a Circle to access its chat view
• Click on the Information tab on the right, and wait for the list of members to load
• Then click on the edit button and again, wait for the list of members to load

I am available to help here, by testing or debugging or what not. Do not hesitate to ask for my contribution. We need the app to load at market speed, it can't be slower.

changed milestone to %Projects part I

By Alexandre on 2019-10-24T21:19:48 (imported from GitLab project)

Is the use case you described here the main pain point regarding performances or is there more?

I am trying to figure out what takes so much time

I'm not sure why but it seems that the sib-ac-checkers are very slowing down the display of the widget team-template-edit. Can you try to remove it and re-test again?

@matthieu: Yes, the issue is only performance here. The time it takes to display the list of 13 members of the Test Circle worries me. We will quickly have circles with dozens of members in the coming weeks, and hundreds in the coming months.

I added a GIF to the issue's description to illustrate my point better.

By Alexandre on 2019-10-25T08:35:08 (imported from GitLab project)

changed the description

By Alexandre on 2019-10-25T08:36:36 (imported from GitLab project)

@jbpasquier, @christophehenry: can one of you assist @matthieu here?

By Alexandre on 2019-10-25T08:37:32 (imported from GitLab project)

No more sib-ac-checker on test-paris, still slow.

as slow as Alex showed or better? And what if you remove the team-template-edit widget?

As slow as.

Published without team-template-edit now, it's pretty faster.

@alexandre was the one with the most of pain with his laptop on, maybe if he could give a try too.

@matthieu it looks like you've done quite some progress on understanding the performance issues of the framework. It's great.

I'm a little concerned that one can break the performance just by adding a custom widget. But it's probably part of the widget refactoring to prevent that.

@sylvain Yes it's a problem and I hope that the widget refactoring can help on this

@jbpasquier to check if the problem comes from the sib-display in the widget, can we try to replace it by this:

<template>
${await value['user.account.picture']}
</template>

I agree with @sylvain that it is cool the work you are doing @matthieu

By Alexandre on 2019-10-25T09:11:35 (imported from GitLab project)

@matthieu I published as is, it's really slow.

I feel like it's due to JS processing, because I don't see that much requests in the inspector, and on my machine, if it could be better, I guess it's not that bad. What do you think of this preview compared to your tests?

Faster. Still a bit weird to have undefined for 3 seconds before getting access to data but let's take baby steps I guess.

Do we understand why we get those 3 seconds delay? Also it feels to me that we should not render undefined first, and then the data but only render the data. What I know is that DOM manipulation is very costly, and it feels we are doing a lot of it.

I know React and the likes do a good job at avoiding DOM manipulation as much as possible. Might be worth double checking how they do it. I say all this being far away from the topic so it might not be relevant.

By Alexandre on 2019-10-25T09:31:02 (imported from GitLab project)

For the undefined thing, I think it will be fixed in the widget refactoring. I'll check because it might also be a quick bugfix in 0.9

The 3 seconds delay is a bit strange to me. I need to dig deeper to understand why a sib-display costs so much to show up

Isn't due to the await?

ah yes you can remove the await when you access the @id of a resource, this is synchronous.

For the others cases, LDFlex should keep in cache all the values that it already fetched so the await should resolve quickly.

I'm not sure of what I've to change here. Still not clear for me when to use await or not.

I changed sib-ac-checker from await value['@id'] to value['@id'].

I leaved the sib-display on await value.user.

Is it the right way?

Yes that's it. only the @id is synchronous. But I think that if you let the await it does not change anything

@jbpasquier, @matthieu: next step? :-)

By Alexandre on 2019-10-25T16:13:45 (imported from GitLab project)

@matthieu I haven't been very available this week. But this performance matter is a priority. If it helps, we can have a call on Monday to discuss it and see how to tackle it.

Yes maybe we can have a call today!

Issue posted on LDFlex here: https://github.com/solid/query-ldflex/issues/45

I'll ping in 24h

By Alexandre on 2019-10-28T14:26:20 (imported from GitLab project)

closed