On Wed, 2007-08-15 at 09:32 -0700, Chris Lattner wrote:> On Tue, 14 Aug 2007, David Greene wrote: > >> Yes, this is one advantage, another is that we wouldn't have to fix the > >> same bug in multiple places :) > > > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > > given the current design. > > Ok, cool. > > > I'm trying out a few interesting things here based on custom streambufs. > > It requires some surgery to AsmPrinters as a std::ostream won't work > > anymore due to the enhanced functionality of the custom streambufs. > > Is this still interesting to the larger LLVM community? One thing I have > > to do is figure out how to handle asm dumps to cerr. > > It really depends on what you mean. I've found that iostreams are > extremely slow, much slower than C stdio streams. Eventually I'd like to > move them to stdio, not to more complex streambufs :)Eventually I'd like to move them to native syscalls adapted by lib/System and suited to the purposes of compilers :) Reid.> > -Chris >
On Wednesday 15 August 2007 13:10, Reid Spencer wrote:> > It really depends on what you mean. I've found that iostreams are > > extremely slow, much slower than C stdio streams. Eventually I'd like to > > move them to stdio, not to more complex streambufs :) > > Eventually I'd like to move them to native syscalls adapted by > lib/System and suited to the purposes of compilers :)I was just about to say that. While debugging my custom streambuf I had the "opportunity" of investigating how libstdc++-v3 defines cout and friends. It's not pretty. Basically, there's a stdio_sync_filebuf used as a proxy to C's FILE *. Because stdio_sync_filebuf does no buffering itself (delegating that to FILE), basic_streambuf::overflow is called a lot. Some of this is mitigated with xsputn for multiple characters, but it's a lot of virtual function calls. To get something faster probably means a custom buffering solution (which my custom streambuf has, but is not particularly intelligent) and native syscalls. The downside of my implementation is that it is POSIX-specific and thus won't be real useful for Windows. -Dave
On Wed, 15 Aug 2007, David Greene wrote:> I was just about to say that. While debugging my custom streambuf I had the > "opportunity" of investigating how libstdc++-v3 defines cout and friends. > It's not pretty. Basically, there's a stdio_sync_filebuf used as a proxy to > C's FILE *. Because stdio_sync_filebuf does no buffering itself (delegating > that to FILE), basic_streambuf::overflow is called a lot. Some of this is > mitigated with xsputn for multiple characters, but it's a lot of virtual > function calls.Yes, it is extremely inefficient.> To get something faster probably means a custom buffering solution (which > my custom streambuf has, but is not particularly intelligent) and native > syscalls. The downside of my implementation is that it is POSIX-specific > and thus won't be real useful for Windows.Why not just use the unlocked stdio calls? -Chris -- http://nondot.org/sabre/ http://llvm.org/