Displaying 5 results from an estimated 5 matches for "pr23395".
Did you mean:
pr20995
2015 Aug 12
2
SmallString + raw_svector_ostream combination should be more efficient
...x64 machine it runs in 1010ms with the current code and in 440ms
> > with the patch applies. Is this OK to commit?
> >
> >
> > 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>:
> >>
> >> Following a hint from Duncan in http://llvm.org/pr23395, here is a
> revised
> >> patch. Rather then introduce the raw_char_ostream adapter, this version
> >> improves raw_svector_ostream.
> >>
> >> raw_svector_ostream is now a very lightweight adapter, running without a
> >> buffer and fowarding almost an...
2015 May 22
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
...e testcase for the raw_svector_ostream patch. On my
WIndows x64 machine it runs in 1010ms with the current code and in 440ms
with the patch applies. Is this OK to commit?
2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>:
> Following a hint from Duncan in http://llvm.org/pr23395, here is a
> revised patch. Rather then introduce the raw_char_ostream adapter, this
> version improves raw_svector_ostream.
>
> raw_svector_ostream is now a very lightweight adapter, running without a
> buffer and fowarding almost anything to the SmallString. This solves both
> t...
2015 Aug 13
2
SmallString + raw_svector_ostream combination should be more efficient
...> 440ms
> >> > with the patch applies. Is this OK to commit?
> >> >
> >> >
> >> > 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>:
> >> >>
> >> >> Following a hint from Duncan in http://llvm.org/pr23395, here is a
> >> >> revised
> >> >> patch. Rather then introduce the raw_char_ostream adapter, this
> version
> >> >> improves raw_svector_ostream.
> >> >>
> >> >> raw_svector_ostream is now a very lightweight adapter, run...
2015 May 02
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
...unused it will heap allocate for no reason.
>
> A careful programmer who did size the SmallString to match its use + small
> reserve will find either of these heap allocations surprising, negating the
> SmallString advantage and then paying memcpy cost.
>
> I filed http://llvm.org/pr23395 about this. To temporarly avoid this
> issue, in addition to the outline methods change I commented the OS.reserve
> line in flush(). (This change of course requires further review.)
>
> With reserve being out of the way, the gap now is smaller but still
> significant: raw_char_ostre...
2015 May 02
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
Could you dig into why:
+ raw_ostream &write(unsigned char C) override {
+ grow(1);
+ *OutBufCur++ = C;
+ return *this;
+ }
Is 3 times as fast as raw_svector_ostream? I don't see a good reason why
that should be any faster than:
raw_ostream &operator<<(char C) {
if (OutBufCur >= OutBufEnd)
return write(C);
*OutBufCur++ = C;
return *this;
}