Re: streambuf performance 200x

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Fri, Feb 14, 2003 at 02:21:03PM -0700, Martin Sebor wrote:
> Nathan Myers wrote:
> >
> > Ask!  If the text doesn't make it clear, the text needs to be fixed.
> > We don't know what to fix if nobody speaks up about what is confusing.
> 
> You know I have been, but there doesn't seem to be much interest
> in iostreams or locale among the committee members (present
> company excluded). Unfortunately, many of my posts regarding
> these areas elicit few if any responses (e.g., c++std-lib-10581,
> c++std-lib-10502, c++std-lib-10579, c++std-lib-10615).

I apologize for my own laxity in this area.  I will look into
those postings and do what I can.

> >>If I'm free
> >>to ignore the Note completely, then the constant bit means nothing
> >>and overflow() is free to write all over the buffer. In fact, since
> >>the behavior of overflow() itself is described in D.7.1.3. p3 by
> >>non-normative Notes, palloc becomes meaningless as well. I think
> >>you would be shocked if the palloc argument ended up being ignored
> >>by an implementation of strstreambuf no matter how fast it was.
> >
> > Since the text describing allocation using palloc is normative,
> > the behavior is certainly required.
> 
> I'm sorry to get sidetracked by this, but I must respectfully
> disagree. Besides the interface, the value of palloc is only
> mentioned in Tables 101, 102, and 103. 

I believe those tables are normative.

> What it's used for is
> only explained in the non-normative Note(s) in D.7.1, p3 and
> D.7.1.3, p3.  If, as you say below, non-normative text doesn't
> present any new requirements, there is no requirement at all
> on what palloc is supposed be used for. And the same is also
> true for constant, and for the effects of the frozen bit on
> the output sequence.

The second of those is normative.  Only the text in square brackets
like "[Note: ... --end note] is non-normative.  The "Notes:" 
sections of function descriptions are normative.  See 1.5p6.
Just because it says "Notes:" doesn't make it an ISO "note". :-P

> This isn't the only example. To give you another, the Note in
> 20.4.1.1, p3 says that allocator::allocate() uses operator new().
> There is no normative requirement that allocate() do so. ...

Likewise.
 
> And it doesn't end with Notes. The inconsistencies extend to
> and are especially wide-spread among the Effects and Returns
> clauses in iostreams where most of the public streambuf functions
> are not actually required to call the protected virtuals. They're
> just required to return the same values because the normative text
> mistakenly uses a Returns instead of an Effects clause (see, for
> instance, 27.5.2.2.2, p1, p2, p3, and p4). The importance of this
> is that if the standard were actually intended to allow the
> bypassing of the virtual function calls (which I'm told by Jerry
> Schwarz it never was), a set of new optimization opportunities
> would open up to implementations. The fact that no implementation
> explores these opportunities means that every implementer just
> substituted Effects for Returns w/o being shocked or bemused by
> the loss of performance.

The "as if" rule always applies.  If you can determine that the virtual 
would have been your own code, that itself would not call user code -- 
and thus the user can't tell whether it was called -- and you know what 
it would have returned, you don't have to call it.  

I would expect (or hope, anyhow) to find many uses of the "as if" rule 
in libraries meant for performance-sensitive users.  This particularly
applies to detecting that the "C" locale is in force, and using prior
knowledge of "C" locale semantics.  (That is also the particular reason
for 22.1.1 p6,7.)

In the paragraphs you cite, if the function can determine that the
actual type of the object is (e.g.) filebuf (and not my_derived_filebuf
or my specialized basic_filebuf<my_char>), it can do whatever filebuf 
would do, and nobody's the wiser.  In practice these functions are not
bottlenecks in real programs, so you might as well do the virtual call.

snextc (27.5.2.2.3) is more interesting.  sbumpc isn't virtual, so you 
can open-code what sbumpc would have done, with the only risk that the 
user may have specialized basic_streambuf<my_char>::sbumpc.  If you
worry about that, you might specialize snextc for char and wchar_t
yourself.

> So I think it should be quite understandable, even expected, that
> implementers seeking maximum conformance and especially users may
> interpret even non-normative Notes as requirements.

Since any non-normative Notes that appear to impose requirements beyond
the normative text are mistakes, it would be unsurprising to find users
confused by them.  They are accepting on faith that any requirements
they find in the Notes really do echo requirements in normative text.

Thank you for your offer to file the DR on this.  

Nathan Myers
ncm-nospam@cantrip.org