Steven Schveighoffer wrote:
On Thu, 12 Nov 2009 10:29:17 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
I think the best option for toString is to take an output range and
write to it. (The sink is a simplified range.)
Bad idea...
A range only makes sense as a struct, not an interface/object. I'll
tell you why: performance.
You are right. If range interfaces accommodate block transfers, this
problem may be addressed. I agree that one virtual call per character
output would be overkill. (I seem to recall it's one of the reasons
why C++'s iostreams are so inefficient.)
IIRC, I don't think C++ iostreams use polymorphism
Oh yes they do. (Did you even google?) Virtual multiple inheritance, the
works.
http://www.deitel.com/articles/cplusplus_tutorials/20060225/virtualBaseClass/
, and I don't think
they use the "one char at a time" method.
Well they do offer one char at a time and also a block transfer.
http://msdn.microsoft.com/en-us/library/760t8w1z%28VS.80%29.aspx
I'm not sure how the heck but they still manage to call one virtual
method per char, otherwise they'd be plenty fast, which they aren't. I
seem to recall write() has a default implementation that calls put() in
a loop or something. It's not a topic that I want to study closely.
iostreams suck, why spend time on learning the quirks of a broken design.
Ranges are special in two respects:
1. They are foreachable. I think everyone agrees that calling 2
interface functions per loop iteration is much lower performing than
using opApply, which calls one delegate function per loop. My
recommendation -- use opApply when dealing with polymorphism. I
don't think there's a way around this.
>
2. They are useful for passing to std.algorithm. But std.algorithm
is template-interfaced. No need for using interfaces because the
correct instatiation will be chosen.
If you are intending to add a streaming module that uses ranges,
would it not be templated for the range type as std.algorithm is? If
not, the next logical choice is a delegate, which requires no vtable
lookup. Using an interface is just asking for a performance penalty
for not much gain.
I think the cost of calling through the delegate is roughly the same
as a virtual call.
Not exactly. I think you are right that struct member calls are faster
than delegates, but only slightly. The difference being that a struct
member call does not need to load the function address from the stack,
it can hard-code the address directly.
However, virtual calls have to be lower performing because you are doing
two indirections, one to the class vtable, then one to the function
address itself. Plus those two locations are most likely located on the
heap, not the stack, and so may not be in the cache.
I think the only way to figure is to measure. For one thing I disagree
with the comment about the cache - a vtable is quite likely to be warm
after a couple of calls.
I know one thing - Walter's old format function used delegates and it
was unusably slow.
x.toString(outputRange, format)
and
x.toString(&outputRange.sink, format)
is pretty darn minimal, and if outputRange is an interface or
object, this saves a virtual call per buffer write. Plus the second
form is more universal, you can pass any delegate, and not have to
use a range type to wrap a delegate.
Don't fall into the "OOP newbie" trap -- where just because you've
found a new concept that is amazing, you want to use it for
everything. I say this because I've seen in the past where someone
discovers the power of OOP and then wants to use it for everything,
when in some cases, it's overkill. Just look at some Java "classes"...
There is no need to worry that I'll fall into at least that particular
OOP newbie trap.
What I think we should do is define a text output interface that
allows writing individual characters of all widths and also arrays of
all widths. That would be a universal means for text output.
interface TextOutputStream {
void put(dchar); // also accommodates char and wchar
void put(in char[]);
void put(in wchar[]);
void put(in dchar[]);
}
The toString method (re-baptized as toStream) would take such an
interface. Better ideas are always welcome. Perhaps I'm falling
another OOP newbie trap! (Seriously!)
This still fits within a single function, which takes one of the 3
widths (pick one, they can all be translated to eachother):
void put(in char[] str)
{
foreach(dchar dc; str)
{
put((&dc)[0..1]);
}
}
Note that you probably want to build a buffer of dchars instead of
putting one at a time, but you get the idea.
I don't get the idea. I'm seeing one virtual call per character.
Also, putting a single character is probably pretty uncommon, but can be
handled in a similar fashion.
I'm not sure about the uncommonality of outputting one character, but it
may be good to discourage it just to not foster slow code.
That being said, one other point that makes all this moot is -- toString
is for debugging, not for general purpose. We don't need to support
everything that is possible. You should be able to say "hey, toString
only accepts char[], deal." Of course, you could substitute wchar[] or
dchar[], but I think by far char[] is the most common (and is the
default type for string literals).
I was hoping we could elevate the usefulness of toString a bit.
That's not to say there is no reason to have a TextOutputStream object.
Such a thing is perfectly usable for a toString which takes a char[]
delegate sink, just pass &put. In fact, there could be a default
toString function in Object that does just that:
class Object
{
...
void toString(delegate void(in char[] buf) put, string fmt) const
{}
void toString(TextOutputStream tos, string fmt) const
{ toString(&tos.put, fmt); }
}
I'd agree with the delegate idea if we established that UTF-8 is favored
compared to all other formats.
Andrei
