Opening editor takes 7 seconds

@marcushellberg commented on Fri Aug 10 2018

Opening the editor window for the first time takes an unreasonably long time. It gives a bad impression of Vaadin in my opinion.

Of the 7 seconds, 5 are spent on the server. See attached screenshot and chrome perf recording.

https://transfer.sh/3jOrC/bb-open-editor.json

---

The issue has been originally created in beverage repo. But this is a generic performance issue with com.vaadin.flow.component.internal.ComponentMetaData.findDependencies method execution (see comments from Leif below). So this needs design and a proper solution since at the moment there is no obvious way how to solve it. We are doing everything possible at the moment: cache the result but it’s necessary to run it a least one time.

---

@denis-anisimov commented on Sat Aug 11 2018

Steps to reproduce?

Does it happen with an empty dialog and just calling it open method ?

---

@marcushellberg commented on Sun Aug 12 2018

1. Download latest starter from vaadin.com/start
2. Run app
3. Click edit on any beverage

---

@denis-anisimov commented on Sun Aug 12 2018

OK, thanks.

---

@denis-anisimov commented on Wed Aug 15 2018

True, the very first time the dialog loading takes very long time. Every subsequent call of any other dialog works well.

---

@denis-anisimov commented on Wed Aug 15 2018

There is no any explicit performance issues on the server side when the dialog is requested being opened. All server side logic is executed right away. The problem is the dialog content: it has many components which have not been loaded anyhow previously. Here is the attached image of the resources that are loaded on dialog load request:

So I guess the reason of the behavior: is the first time loading a bunch of remote resources from webjars. That’s why it doesn’t happen any subsequent time.

I don’t see what we can do in general here. May be something in this specific case preload some components which are expected to be used anyway because most likely a user will open some dialog…

---

@Legioth commented on Wed Aug 15 2018

The time it takes to load the HTML imports isn’t the main problem. There’s a significant time spent in the UIDL request: 2.10s now when I tested it. After a couple of repetitions to let the JVM and any of Flow’s own caches to warm up, the server-side time goes down to around 100ms on my machine. This is still quite much compared to the initial view which takes around 50ms of server-side time for both generating UIDL and producing the HTML page.

---

@Legioth commented on Wed Aug 15 2018

According to JProfiler, most of the time is spent in com.vaadin.flow.component.internal.ComponentMetaData.findDependencies. The result of this is cached so it only happens the first time the code is run after the application has been started.

Out of the time spent in that method, about 60% is spent in javax.servlet.ServletContext.getResourceAsStream, which basically does IO to read and unzip files from inside various webjars.

---

@denis-anisimov commented on Wed Aug 15 2018

Well, I was able to reduce the opening time via just adding lazy pre-load of the components.

findDependencies is more tricky since it’s needed to be called and this is the server-side time during the request. The only way how it may be reduced is creating a background thread which collects dependencies and put them into the cache before the dialog is even opened…

---

@Legioth commented on Wed Aug 15 2018

One approach for findDependencies might be to whitelist dependencies that we know might be encountered, but that are not necessary to parse through since we know that nothing of interest will be found through them.

---

@Legioth commented on Wed Aug 15 2018

To make things even more advanced, we could even automatically precompute the dependencies for each of our components and include a manifest in the .jar file.

---

@marcushellberg commented on Wed Aug 15 2018

@denis-anisimov’s solution is OK in the context of this demo. But ideally, we would come up with a solution where a developer doesn’t accidentally introduce this kind of slowness into their app by just using our APIs as documented.

---

@denis-anisimov commented on Wed Aug 15 2018

True, true.

But there are real reasons behind that behavior. So it requires a serious design in Flow to avoid such issues.

[denis-anisimov]

Agreed. OK, let’s start with that and exclude everything inside frontend://bower_components/polymer/

[Legioth]

We can be really sure that frontend://bower_components/polymer/ won’t contain anything that would be related to themes. Only blacklisting that one and nothing else would by itself improve performance by 80%.

If there are still performance problems after fixing the caching and blacklisting frontend://bower_components/polymer/, then we might evaluate whether we could somehow also blacklist (or precompute) more stuff, but until that, I don’t think any more blacklisting would be necessary.