[LLVMdev] Extending AsmPrinter
Chris Lattner
sabre at nondot.org
Fri Aug 17 15:01:46 PDT 2007
On Fri, 17 Aug 2007, David Greene wrote:
> Ah. Basically operator<< for FILE*. I don't see a lot of benefit to
> redefining operator<< for every type just to avoid ostreams. The
> problem isn't basic_ostream _per_se_. There are two issues we're
> worried about:
The problem is basic_ostream and the design of the whole iostreams
library. Use of virtual base classes makes every virtual method
particularly expensive, for example.
> 1. The static constructor contortions in place to handle the extremely
> unlikely case of a static object constructor writing to one of the
> standard streams.
I also dislike this strongly, but it isn't really related.
> 2. Slowness of std::cout and friends due to their reliance on FILE *
> buffering and resulting excessive virtual function calls.
Use of FILE* is not the issue, virtual functions are.
> I just implemented "standard" AsmStreams (the name for my custom streams) to
> handle the cases where we want to dump Asm to standard error. I just point
> the AsmStreambuf to STDERR_FILENO. I simply avoid the constructor issue by
> declaring that no user shall write to an AsmStream in a static object
> constructor. So we don't have worries about multiple constructor calls at
> program startup. There is no ios_base::Init equivalent for AsmStream.
This gives you the virtual overhead of streams without the buffering
overhead of FILE*. Instead of the buffering overhead of stdio you have
your own different but exactly equivalent buffering overhead.
> The second concern is addressed as described earlier. I do the buffering
> at the AsmStream level to minimize virtual calls.
How is this different than buffering done by stdio?
> This will still be slightly slower than raw FILE * or POSIX calls because
> there will be some virtual function call overhead. But it should be much
> better than standard streams and we get all of the nice benefits of iostreams.
The only problem you seem to have solved is avoiding having to define a
few operator<<'s, this doesn't seem like a very good tradeoff to me.
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
More information about the llvm-dev
mailing list