Increased warm startup times in vLatest compared to v14

[tarekoraby]

Description of the bug / feature

The average warm-startup times in latest versions of the framework (e.g. 21.0.1) are appreciably longer than in v14.x (approx. 50% longer).

Minimal reproducible example

Calculate warm-startup times for 14.6.9 and 21.0.1

1. Download empty project starter (plain Java servlet) from vaadin.com starter service
2. Update Vaadin version in pom.xml
3. Remove package.json, package-lock.json, and pnpm-lock.yaml to simulate manually created empty project
4. Run mvn jetty:run -nsu -Dvaadin.ignoreVersionChecks=true -DskipTests with the correct profile
5. Wait bootstrap page being served; ignore if devServerIsNotLoaded: true is present (work around live reload)
6. Download all scripts referenced in the bootstrap page
7. Terminate maven process
8. Start timer
9. Repeat steps 4 to 7
10. Stop Timer (to collect statistics for a warm run)

Expected behavior

There is no significant difference in the warm-startup performance between Flow versions.

Actual behavior

21.0.1 is significantly slower (approx. 16 sec) compared to 14.6.9 (approx. 10 sec.) to warm start.

Versions:

- Vaadin / Flow version: 21.0.1

[caalador]

Test with 21.0.2 as it should be fixed with #11853 as was for #11910

[tarekoraby]

The same slow warm startup times are observed in 21.0.2 (see the results of the automated performance tests at the bottom of this report).

[tarekoraby]

I'm not sure what the Fusion label signifies, but I just want to emphasize that these relatively slow times are observed in pure Flow projects.

[caalador]

Fusion has added quite a lot of steps to the webpack build slowing it down from what it was in v14
Also just having a look at the report the situation hasn't really changed from v20 and probably is close to the same with 17,18 and 19. A correct comparison to the times should be in the v15+ versions instead of against v14

[caalador]

Also see work done for v19: #10281

[tarekoraby]

A correct comparison to the times should be in the v15+ versions instead of against v14

Yep, that's true. The issue is indeed noticeable since v15+. And it would be great if we could improve it before the next LTS.

[tarekoraby]

And to clarify, the issue that I think that we should be mainly concerned with is the DX of someone migrating from V14 to the next LTS.

[knoobie]

The old issue was created by me.. I'm kinda used to it by now that V15+ needs twice the amount of time to "build".. but I would be happy to get the old speed back as well.

[HelmerBarcos]

Im having this issue too. Im trying to migrate a project with more than 4.3K java files from vaadin 8 to vaadin 21.0.2 and the webpack server just doesn't start. Im not able to see any frontend on the Browser after 12 min, when I decide to kill the process. It is an issue related to npm oder webpack? I also set the vaadin.whitelisted-packages prop for the package where the frontend logic will be. But my project is using java files for Flow and .ts files for Fusion.

I have this error

Exception in thread "File Watcher" java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:3332)
        at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
        at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649)
        at java.lang.StringBuilder.append(StringBuilder.java:202)
        at java.io.UnixFileSystem.resolve(UnixFileSystem.java:108)
        at java.io.File.<init>(File.java:262)
        at java.io.File.listFiles(File.java:1212)
        at org.springframework.boot.devtools.filewatch.DirectorySnapshot.collectFiles(DirectorySnapshot.java:63)
        at org.springframework.boot.devtools.filewatch.DirectorySnapshot.collectFiles(DirectorySnapshot.java:67)
        at org.springframework.boot.devtools.filewatch.DirectorySnapshot.collectFiles(DirectorySnapshot.java:67)
        at org.springframework.boot.devtools.filewatch.DirectorySnapshot.collectFiles(DirectorySnapshot.java:67)
        at org.springframework.boot.devtools.filewatch.DirectorySnapshot.collectFiles(DirectorySnapshot.java:67)
        at org.springframework.boot.devtools.filewatch.DirectorySnapshot.collectFiles(DirectorySnapshot.java:67)
        at org.springframework.boot.devtools.filewatch.DirectorySnapshot.<init>(DirectorySnapshot.java:58)
        at org.springframework.boot.devtools.filewatch.FileSystemWatcher$Watcher.getCurrentSnapshots(FileSystemWatcher.java:304)
        at org.springframework.boot.devtools.filewatch.FileSystemWatcher$Watcher.scan(FileSystemWatcher.java:278)
        at org.springframework.boot.devtools.filewatch.FileSystemWatcher$Watcher.run(FileSystemWatcher.java:263)
        at java.lang.Thread.run(Thread.java:748)

[knoobie]

@HLBp That's not really related to this issue. Looks more like a problem on the spring (boot) devtool side of things. You probably want to create a issue there, not here.

[HelmerBarcos]

@knoobie I just increased the maximum memory value by setting the -Xms4G -Xmx8G args and the OutOfMemoryError did disappear. But the webpack-dev-server is still taking more than 3 mins to start the frontend compilation. In other words. the task on the vaadin/java side that starts the webpack-dev-server is taking a couple of minutes before starting the node process.

[caalador]

@HLBp This sounds like a Spring(-boot) issue. Try starting with mvn spring-boot:run -Pproduction (or add the build-frontend goal to the vaadin plugin to get pseudo dev mode running) and see if the issue persists in the same way. If it does then open up a new ticket for flow with more details, else open a issue in the Spring project with more details or ask from the Spring team if they would have some insights.

[platosha]

Now that we have some improvements for this coming with the Vite support, should we close this issue?

[tarekoraby]

Let's compare the startup times between vLatest and v14 before making a decision on closing the issue.

[tarekoraby]

Here is an updated report of the cold and warm startup times of the different versions: https://bender.vaadin.com/repository/download/DxTutorialStarter_BuildPerformanceTestsRunningInDevelopmentMode/326140:id/human-readable-report.html.

[tarekoraby]

@mshabarov, perhaps this issue can be closed after the startup improvements due to the pre-compiled bundle.

[mshabarov]

@tarekoraby we need to reproduce and check.