Displaying 4 results from an estimated 4 matches for "1010ms".
Did you mean:
100ms
2015 Aug 12
2
SmallString + raw_svector_ostream combination should be more efficient
...makes write virtual. What is the impact of that on the other
> streamers?
>
>
>
> On 22 May 2015 at 10:17, Yaron Keren <yaron.keren at gmail.com> wrote:
> > Here's a performance 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
> revis...
2015 May 22
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
Here's a performance 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...
2015 Aug 13
2
SmallString + raw_svector_ostream combination should be more efficient
...t; >> streamers?
> >>
> >>
> >>
> >> On 22 May 2015 at 10:17, Yaron Keren <yaron.keren at gmail.com> wrote:
> >> > Here's a performance 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 f...
2015 May 02
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
+update diff
2015-05-02 7:38 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>:
> I outlined (is that the right
> word?) raw_char_ostream::grow, raw_char_ostream::write (both) into
> raw_ostream.cpp with less than 10% difference in performance.
>
> Profiling reveals that the real culprit is the code line
>
> OS.reserve(OS.size() + 64);
>
> called from