- From: Nicolas Gilbert <notifications@github.com>
- Date: Thu, 13 Apr 2023 08:29:08 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/989/1507173442@github.com>
One important benefit would be performance, both from a memory and runtime execution point of view. For large applications, the number of custom registries could become very large, and many of those registries would be near identical, with only a couple of local component added to some shared components. Maybe browsers can to some magic there, so I might be wrong about the impact about memory, but if we are forced to hold in memory identical definitions, it does not feel quite right. From a runtime performance point of view, there could be large numbers of identical `define` at startup. This is the point I am the most worried about. I did some quick perf test, see below. --- You're correct concerning the contradiction. I will have to think about it a bit more, but my first feeling would be that either prefixing could be defined globally as a static method instead of when getting the registry, or maybe a lib could decide to subclass. I would prefer option 1, but this is userland so multiple ways of doing things would be ok. That is unless the localName could be updated after connection. I suspect there are good reason not to and I don't think it can be polyfilled easily, but allowing localName to mutate on connection would alleviate those issues. Some kind of aliasing feature where a constructor always have a single registry, but can be aliased unto other registries. --- I did some quick perf tests, nothing very scientific. Interestingly, Safari is more performant than Chrome for large number of definitions, so it'll be interesting to test on entry level Android devices. Anyway, it seems to confirm that keeping the number of definitions as low as possible do matter. |Device|Is extending|Registry count|Shared element count|Local element average count|Runtime| |--|--|--|--|--|--| |Laptop (Chrome)|false|2000|200|5|~450ms| |iPhone 13|false|2000|200|5|~250ms| |iPhone 6|false|2000|200|5|~2,500ms| ||||||| |Laptop (Chrome)|false|500|50|5|~18ms| |iPhone 13|false|500|50|5|~18ms| |iPhone 6|false|500|50|5|~172ms| ||||||| |Laptop (Chrome)|false|200|20|2|~2.5ms| |iPhone 13|false|200|20|2|~3ms| |iPhone 6|false|200|20|2|~28ms| ||||||| |Laptop (Chrome)|true|2000|200|5|~22ms| |iPhone 13|true|2000|200|5|~9ms| |iPhone 6|true|2000|200|5|~177ms| ||||||| |Laptop (Chrome)|true|500|50|5|~6ms| |iPhone 13|true|500|50|5|~2ms| |iPhone 6|true|500|50|5|~29ms| ||||||| |Laptop (Chrome)|true|200|20|2|~1ms| |iPhone 13|true|200|20|2|~1ms| |iPhone 6|true|200|20|2|~7ms| See methodology: https://github.com/chalbert/web-specs-utils -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/989#issuecomment-1507173442 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/989/1507173442@github.com>
Received on Thursday, 13 April 2023 15:29:13 UTC