Displaying 7 results from an estimated 7 matches for "raw_char_ostream".
2015 May 02
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
...non-inlined, in which case your patch might be a complicated way to pull
the likely cases of some raw_ostream methods into the header.
-- Sean Silva
On Thu, Apr 30, 2015 at 8:02 PM, Yaron Keren <yaron.keren at gmail.com> wrote:
> Yes, we should do without virtual flush. The problem was raw_char_ostream
> should not be flushed - it's always current - so I overloaded flush to a
> no-op. A cleaner solution is attached, adding a DirectBuffer mode to the
> raw_ostream.
>
> Also added a simple performance comparison project
> between raw_char_ostream and raw_svector_ostream. On Wi...
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 raw_svector_ostream::write_impl called from
> raw_svector_...
2015 Aug 12
2
SmallString + raw_svector_ostream combination should be more efficient
...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
> >> the performance issue and...
2015 May 22
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
...achine 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
> the performance issue and the information duplication issue. The
> Small...
2015 Apr 30
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
I don't think we should make flush virtual. Why do you need to do it?
Can't you set up the base class to write to use the tail of the memory
region as the buffer?
On 24 April 2015 at 06:46, Yaron Keren <yaron.keren at gmail.com> wrote:
> Hi,
>
> Is this what you're thinking about?
> The code is not tested yet, I'd like to know if the overall direction and
>
2015 Aug 13
2
SmallString + raw_svector_ostream combination should be more efficient
...t; >
> >> > 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 Small...
2015 Apr 20
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
Sean, thanks for reminding this, Alp did commit a class derived from
raw_svector_ostream conatining an internal SmallString he called
small_string_ostream.
The commit was reverted after a day due to a disagreement about the commit
approval and apparently abandoned.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223393.html