[llvm-commits] [llvm] r78924 - in /llvm/trunk: include/llvm/Support/raw_ostream.h lib/Support/raw_ostream.cpp

[Daniel Dunbar]

I'm backing this out for now, it definitely made
raw_{string,svector}_ostream slower in my timings (on a synthetic
benchmark):

std::string:
--
r79347:
name	  avg  	  min  	  med  	  max  	   SD  	 total
user	 0.6161	 0.6158	 0.6158	 0.6168	 0.0005	 1.8484
 sys	 0.0789	 0.0780	 0.0784	 0.0805	 0.0011	 0.2368
wall	 0.6967	 0.6952	 0.6958	 0.6991	 0.0017	 2.0901
r79347 w/ 78924 backed out:
name	  avg  	  min  	  med  	  max  	   SD  	 total
user	 0.3787	 0.3785	 0.3787	 0.3788	 0.0001	 1.1360
 sys	 0.0790	 0.0786	 0.0800	 0.0783	 0.0007	 0.2370
wall	 0.4591	 0.4583	 0.4603	 0.4587	 0.0008	 1.3773
--

The svector stream shows the same change. For reference, these are the
times for llvm::outs():
--
name	  avg  	  min  	  med  	  max  	   SD  	 total
user	 0.2983	 0.2981	 0.2984	 0.2985	 0.0002	 0.8950
 sys	 0.0019	 0.0018	 0.0020	 0.0018	 0.0001	 0.0056
wall	 0.3052	 0.3008	 0.3014	 0.3134	 0.0058	 0.9156
--

I'll work today on getting rid of the unnecessary extra malloc/free
calls for those kinds of streams.

 - Daniel

On Thu, Aug 13, 2009 at 5:20 PM, Chris Lattner<clattner at apple.com> wrote:
>
> On Aug 13, 2009, at 10:55 AM, Daniel Dunbar wrote:
>
>> On Thu, Aug 13, 2009 at 10:41 AM, Dan Gohman<gohman at apple.com> wrote:
>>>
>>> Author: djg
>>> Date: Thu Aug 13 12:41:40 2009
>>> New Revision: 78924
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=78924&view=rev
>>> Log:
>>> Set raw_os_ostream, raw_string_ostream, and raw_svector_ostream to be
>>> unbuffered. std::ostream does its own buffering, and std::string and
>>> SmallVector both have allocation strategies intended to handle frequent
>>> appending.
>>
>>
>> Eek!
>>
>> Did you profile the effects of this change? I expect that this
>> dramatically slows down these streams. One of the main values of being
>> buffered in raw_ostream is that we hit all the fast paths to quickly
>> output small strings. Making all of these strings unbuffered nullifies
>> several of these optimizations.
>
> Yes, I'm really scared of this too.  The whole idea of raw_ostream is to
> inline the trivial "o << 'c'" calls.  This doesn't help if the inlined code
> is always calling flush!
>
> -Chris
>
>