LitTemplate/Polymer Template instantiation time

[hons82]

Description of the bug / feature

As I've already explained in my stackoverflow question, I'm not really happy with the instantiation time of the components created as extension to LitTemplate/PolymerTemplate. My current solution is to extend from Component and work with slots to come across the limitations. There are however some limitiations to this approach. For instance it is not possible yet to add a slot to a vaadin-overlay, as explained here.

Minimal reproducible example

I did create a page in my vaadin sampler to showcase the problem. Those numbers are of course for the first instantiation and get better, it would however be important that the instantiation of more complex components would still be fast. There might be some tweaks in that template parsing to speed this process up.

Expected behavior

Fast, faster, LitTemplate. We have the need to create complex components with the need for Littemplate that should be as fast as possible.

Actual behavior

Instantiation time of the component is to slow. If you take for instance a component that we actually use(it's in the sampler as well) an try to measue it, it currently takes about 20ms for the constructor. If you simplify it to extends Component you'll be able to get it down to almost 0ms.

Versions:

- Vaadin / Flow version: 14.6.7/20.0.6
- Java version: 11
- OS version: Win10
- Browser version (if applicable): Chrome 93.0.4577.82
- Application Server (if applicable): /
- IDE (if applicable): Intelij 21.2.2

[denis-anisimov]

The numbers are confusing. They are valid and not really valid. This is the very first access values. To be able to support @Id mapping the templates are parsed. All the templates nowadays are in one big bundle file and it takes time to parse this file. Once it's parsed the data is cached (globally) and any subsequent access should be much faster. So these number are valid for the very first one single time access across all the application. I disagree that they can be considered as a reference numbers which indicate a performance issue.

[hons82]

This is true. The first access is always slower than the rest, however in our quite huge project, and the autosuggest component mentioned above we're unable to get below 20ms for subsequent instantiations. Is it possible that in huge projects some of this cached values are dropped because of the size of this "one big bundle file"?

Or is it possible to speed the subsequent instantiations up, by using more distinctive names for the @Id fields?

[denis-anisimov]

I don't see any reasons why they could have been dropped. The cache is global and I'm not aware of any code which cleans up the cache. So there shouldn't be any difference.

It doesn't matter which names you are using for @Id fields. I would recommend to avoid @Id at all even though I think there is no code which skips template parsing completely if there is no @id mapping. I think we may improve template instantiation via checking first whether there is any @id mapping at all and skip parsing.

I'm trying to clarify: the ticket in its original description has quite low priority since it's about the very first single component creation which has quite low impact on the performance.

But if you are able to provide the example which proves that there is a performance issue with every template instantiation then this is another issue with another impact.