3 ms·
Right, << and StringBuffer is still less efficient, at least in terms of the asymptotic number of bytes copied. I guess what I'm saying is that if you "properl
by chubot 6y ago
Right, << and StringBuffer is still less efficient, at least in terms of the asymptotic number of bytes copied.
I guess what I'm saying is that if you "properly" write a template engine, there should be no advantage to ropes at all.
Rather than a tree of non-copied fragments in the language runtime (ropes), you can simply create an array of non-copied fragments in the language itself.
Following the template engine I wrote in Python and JS:
- Fragments come from two places: holes and consts. holes come from variables, and consts are figured out at template compile time (e.g. which happens when the web server starts, and shouldn't be benchmarked).
- Fragments are never copied. They are simply appended to a big array of fragments. The template engine is a recursive tree walk interpreter that always appends to an array.
This is even true for a feature like #include. Some template engines may do the "right" thing for local fragments, but the copying may sneak back in for #include. But if you care, it's easy to handle #include in a consistent way.
So if you use that "obvious" architecture, then I claim there should be no advantage to ropes. But I guess that's not what happens in practice!
(Well, seeing some sibling comments about copying being faster, at least the claim is that this architecture should be as fast or as slow as ropes! :) But yeah I think ERB is probably doing something different and even worse, which is not surprising.)
- chrisseaton 6y ago> I guess what I'm saying is that if you "properly" write a template engine, there should be no advantage to ropes at all. If you're building up your string as an array of strings, and you want to pass that to some existing code that expects a full string (like the web framework you're using) then you're going to need to flatten it to create the final full string. Ropes don't need to do that. They still have an advantage. Also... the implementation doing things for you so you don't have to manually optimise your code is kind of the point of an optimisation. We can always say 'but I could do this manually' to any optimisation, couldn't we?
- chubot 6y agoYeah it's a moot point either way, because ERB is like that... but - This wasn't an optimization, it was literally the first thing I thought of when I wrote my first and only template engine 10 years ago. And I have seen plenty of others do it; it is "obvious". The code is the exact same length as the string version, so I don't consider it an optimization. - Python's WSGI accepts an iterable of strings for the body. From a cursory reading, looks like Ruby's rack does too: https://en.wikipedia.org/wiki/Rack_(web_server_interface)#Example_application https://en.wikipedia.org/wiki/Rack_(web_server_interface)#Ex... e.g. it's ["Hello, World"] and not "Hello, World" (I don't know Ruby that well though) Maybe frameworks mess it up in the middle...