`inner_html` is slow

[bicarlsen]

inner_html, used in <Icon> is very slow at scale because it uses web_sys::Element::set_inner_html which uses the Element::innerHTML setter JS call behind the scenes, which is known to be slow.

I have an app where I render many <Icon>s. This caused a massive slow down. Profiling showed the cause of the slow down was due to set_inner_html calls. @gbj tracked it down to the call referenced above.

Is there another way to set the inner HTML for the icons? Can we statically compile them rather than set them with JS?

[bicarlsen]

One option could be to mimic what yew_icons did with their generator feature.

[carloskiki]

I'm sorry to hear that. We previously used a method similar to what yew_icons does, but it was a hassle to maintain. I prefered keeping the icon sources external. What icondata provides is a &'static str containing the inner html. I haven't followed the newest changes to leptos, but maybe the tachys module can help us here. You could take a look at tachys::InertElement and how we could use it to render our elements statically instead.

[bicarlsen]

Yeah, I'm in discussion with @gbj about creating an tachys::InertSvgElement at the moment. He also suggested using the template! macro, but my initial attempts to implement ToTemplate for the <Icon> component haven't been successful.

If you have any sense of the best path to take or how to go about it, I'd love any feedback.

[bicarlsen]

I opened a PR in leptos to add inert SVG elements.

[bicarlsen]

I experimented with a few options to remove the slowness of inner_html calls. I implemented three new icon types:

1. <StaticIcon>: Removes all signals to take advantage of InertSvgElement (as mentioned above), but still uses inner_html.
2. <IconTemplate>: Replaces inner_html with a call to child directly inserting the <path>. This allows ToTemplate to be implmented.
3. <StaticIconTemplate>: Removes inner_html and signals.

I created a tauri app test repo to try profile them (I use leptos for the frontend of my tauri app), and ran some perf profiles.
(The test repo relies on some relative cargo paths being set correctly and that you have the leptos repo with inert SVG locally available, I'll make this more robust in a future push if anybody is interested in trying it themselves. Let me know if I should put the effort into this though.)

(I'm not an expert in profiling, so please take with a grain of salt.)
using the test repo with 10k elements (1000 rows x 10 cols)

	Time to next repaint (s)	Notes
<Icon>	6.9	67% of time spent in inner_html.
<StaticIcon>	4.2	73% of time spent in inner_html.
<IconTemplate>	3.3	No real sign of heavy offender in terms of CPU consumption. inner_html not called.
<StaticIconTemplate>	2.9	inner_html not called.

While an improvement, I still feel like it shouldn't take 3 seconds to paint 10k SVG items, maybe I'm wrong though. If anybody has insights into how else to optimize please try them out or let me know.

I like the idea of creating these different performance based <Icon> variants for specific use cases. @carloskiki, what is your feeling on it?

[carloskiki]

I like IconTemplate and StaticIconTemplate because they do not use inner_html. Since the performance difference between both is quite small, I would be inclined to only implement IconTemplate. What do you think?

Another question, would IconTemplate still allow for dynamic props?

If you want to submit a PR, I would be happy to review and merge it.

[carloskiki]

Also, if IconTemplate works exactly the same as Icon and simply renders faster, I would be happy to replace the current implementation with IconTemplate. No need for two different implementations.

[bicarlsen]

Since the performance difference between both is quite small, I would be inclined to only implement IconTemplate. What do you think?

Even though it's only a 0.4 second difference on 10k items, that's still a boost of 12%. I think we could take a progressive approach, implementing first just IconTemplate, and if that doesn't satisfy my/our needs, add in StaticIconTemplate.

Does IconTemplate still allow for dynamic props?

Yes. I added a little example in the test app to verify this.

if IconTemplate works exactly the same as Icon ...

Some of the icondata::IconData::data have more info than just the path::d attribute, e.g. icondata_ai::AiAccountBookTwotone.
I did a temporary hack in the prototype so I could test this.

The most robust solution would be to parse the data stored in icondata_core::IconData::data during generation and store the data in a structured way, but I'm not sure the best way to do this. Can we store leptos::svg elements there? How hard would it be to parse the data coming in? Can we hijack leptos during the generation phase so it does the parsing for us?

[bicarlsen]

It appears we can expand on the current parsing to parse the inner <path>.

[bicarlsen]

I thought we could use InertElements to get around having to parse the <svg>, but unfortunately it calls Dom::dom::create_element_from_html which calls set_inner_html, so we've gone in a loop.

I've raised an Issue on leptos about this.

[bicarlsen]

I issued a PR in leptos to resolve the set_inner_html issue mentioned above.

Hopefully both leptos PRs get accepted. If so, I'll clean up the <Icon> prototype code and issue a PR :)