IOBuffer does not inherit from string, nor does it implement any of the methods expected of a mutable string (length, endof, insert! / splice! / append!). If you want strings that support all of those operations, then you will need something different from an IOBuffer. If you just wanted a fast string builder, then IOBuffer is the right abstraction (ending with a call to `takebuf_string!`). This dichotomy helps to give a clear distinction in the code between the construction phase and usage phase.
On Sat, May 2, 2015 at 12:49 PM Páll Haraldsson <[email protected]> wrote: > 2015-05-01 16:42 GMT+00:00 Steven G. Johnson <[email protected]>: > >> >> In Julia, Ruby, Java, Go, and many other languages, concatenation >> allocates a new string and hence building a string by repeated >> concatenation is O(n^2). That doesn't mean that those other languages >> "lose" on string processing to Python, it just means that you have to do >> things slightly differently (e.g. write to an IOBuffer in Julia). >> >> You can't always expect the *same code* (translated as literally as >> possible) to be the optimal approach in different languages, and it is >> inflammatory to compare languages according to this standard. >> >> A fairer question is whether it is *much harder* to get good performance >> in one language vs. another for a certain task. There will certainly be >> tasks where Python is still superior in this sense simply because there are >> many cases where Python calls highly tuned C libraries for operations that >> have not been as optimized in Julia. Julia will tend to shine the further >> you stray from "built-in" operations in your performance-critical code. >> > > What I would like to know is do you need to make your own string type to > make Julia as fast (by a constant factor) to say Python. In another answer > IOBuffer was said to be not good enough. > > > -- > Palli. >
