search

k0kubun / hamlit

High Performance Haml Implementation
https://rubygems.org/gems/hamlit
Other
981 stars 59 forks source link

Compilation bottlenecked on StringSplitter#dispatcher #139

Closed stanhu closed 5 years ago

stanhu commented 5 years ago

I profiled an initial rendering of a Rails page that took 2 seconds initially. It looks like a significant amount of time is spent in StringSplitter#dispatcher, which looks like it's calling Kernel#class from https://github.com/judofyr/temple/blob/7987ab67af00a598eb3d83192415371498a0f125/lib/temple/mixins/dispatcher.rb#L65:

image

I'm not sure what it's doing here, but I wonder how we can optimize this?

k0kubun commented 5 years ago

First of all, compilation speed is a trade-off with rendering speed. It should not be terribly slow but at least it's not Hamlit's focus. If you're concerned about compilation time more, you may want to use haml.gem instead.

For your original question, Hamlit::StringSplitter is inheriting Temple::Filter and the #dispatcher is implemented in Temple::Filter as you pointed. The main code seems to be tree.compile.gsub("\n", "\n ") and I'm actually not sure why it needs to check class in that place. If we were able to remove that from the method body, it would be nice (but not sure if we can). The filter in Hamlit is splitting an interpolated string literal in Haml attributes to reduce the number of string concatenations on rendering.

As I don't want to remove this filter from Hamlit, You may want to open this issue in Temple repository to have some insights from other maintainers. Thanks for investigating the bottleneck of Hamlit compilation :)

stanhu commented 5 years ago

@k0kubun Thanks for your response and this gem! I've opened https://github.com/judofyr/temple/issues/124 to follow up.