Compilation bottlenecked on StringSplitter#dispatcher

[stanhu]

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:

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

[k0kubun]

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]

@k0kubun Thanks for your response and this gem! I've opened judofyr/temple#124 to follow up.