Status quo, constructing a HTML fragment builds up a big list of Modifiers, which is then taken apart to build a Builder object, which is then taken apart to fill a StringBuilder
After the first three commits up to 7dc316a, constructing a HTML fragment a Builder object, which is then taken apart to fill a StringBuilder
After all commits in this PR, constructing a HTML fragment directly fills a StringBuilder
This makes Frags and Tags no longer immutable. They never really were, especially in JsDom land where they could contain arbitrary mutable DOM elements, but this would make it official. With this diff, you should no longer assign Frags or Tags to vals: they should be defs and re-computed each time.
text.Builder is now just a StringBuilder, and any Frags that get passed into a Tag get immediately flattened into that StringBuilder
This should build-up/tear-down fewer intermediate data-structures and result in less garbage/memory usage, but somehow still seems to be giving me a 10-20% slowdown rather than a speed-up. Notably, going "halfway" (commit 7dc316a) to make Frags directly affect the Builder but not get immediately flattened, seems to give about a 20% speedup. I've poked around with JProfiler and haven't figured out why putting things into a StringBuilder earlier rather than later is resulting in such a huge slowdown
Status quo, constructing a HTML fragment builds up a big list of
Modifiers, which is then taken apart to build aBuilderobject, which is then taken apart to fill aStringBuilderAfter the first three commits up to
7dc316a, constructing a HTML fragment aBuilderobject, which is then taken apart to fill aStringBuilderAfter all commits in this PR, constructing a HTML fragment directly fills a
StringBuilderThis makes
Frags andTags no longer immutable. They never really were, especially in JsDom land where they could contain arbitrary mutable DOM elements, but this would make it official. With this diff, you should no longer assignFrags orTags tovals: they should bedefs and re-computed each time.text.Builderis now just aStringBuilder, and anyFrags that get passed into aTagget immediately flattened into thatStringBuilderThis should build-up/tear-down fewer intermediate data-structures and result in less garbage/memory usage, but somehow still seems to be giving me a 10-20% slowdown rather than a speed-up. Notably, going "halfway" (commit 7dc316a) to make
Frags directly affect theBuilderbut not get immediately flattened, seems to give about a 20% speedup. I've poked around with JProfiler and haven't figured out why putting things into aStringBuilderearlier rather than later is resulting in such a huge slowdown