Improve WriteUtf8 and WriteAscii.

Improve WriteUtf8 and WriteAscii.

[Yang, 2011-10-25 16:21:44]

Please take a look.

http://codereview.chromium.org/8390004/diff/1/src/api.cc
File src/api.cc (right):

http://codereview.chromium.org/8390004/diff/1/src/api.cc#newcode3649
src/api.cc:3649: }
Flatten as early as possible. FlattenString does nothing else than WriteToFlat.
This way, the WriteToFlat in the Ascii case will be merely a copy from the
already flattened string.

http://codereview.chromium.org/8390004/diff/1/src/api.cc#newcode3729
src/api.cc:3729: if (str->IsAsciiRepresentation()) {
Same thing as WriteUtf8. WriteToFlat is faster than InputBuffer/ReadBlock
because in case of a convoluted cons string, ReadBlock has to hunt down the
right part to read from after every 1024 characters (buffer size).

[Erik Corry, 2011-10-25 19:21:22]

http://codereview.chromium.org/8390004/diff/1/src/api.cc
File src/api.cc (right):

http://codereview.chromium.org/8390004/diff/1/src/api.cc#newcode3729
src/api.cc:3729: if (str->IsAsciiRepresentation()) {
On 2011/10/25 16:21:45, Yang wrote:
> Same thing as WriteUtf8. WriteToFlat is faster than InputBuffer/ReadBlock
> because in case of a convoluted cons string, ReadBlock has to hunt down the
> right part to read from after every 1024 characters (buffer size).

This doesn't do the same with embedded nulls as the previous WriteAscii code. 
That makes me think that our test coverage of WriteAscii is not good enough. 
The treatment of embedded null characters is pretty bogus though, which makes me
wonder if anyone uses this function.

[Yang, 2011-10-26 09:43:52]

Turns out my changes were not well tested to begin with. I added some tests and
fixed the issues.

The null embedding has been fixed by an additional loop doing a replace. It is
still faster this way. I gathered some data. Using WriteAscii on a cons with
length 2^28 and 28 levels, the old version takes 1780ms, the new version takes
1140ms. When using WriteAscii on a cons with length 2^8 and 8 levels a total of
2^20 times, the old version takes 1700ms, the new version takes 990ms.

[Yang, 2011-11-09 12:12:53]

On 2011/10/26 09:43:52, Yang wrote:
> Turns out my changes were not well tested to begin with. I added some tests
and
> fixed the issues.
> 
> The null embedding has been fixed by an additional loop doing a replace. It is
> still faster this way. I gathered some data. Using WriteAscii on a cons with
> length 2^28 and 28 levels, the old version takes 1780ms, the new version takes
> 1140ms. When using WriteAscii on a cons with length 2^8 and 8 levels a total
of
> 2^20 times, the old version takes 1700ms, the new version takes 990ms.

*gentle nudge*

[Yang, 2012-01-16 10:59:43]

On 2011/11/09 12:12:53, Yang wrote:
> On 2011/10/26 09:43:52, Yang wrote:
> > Turns out my changes were not well tested to begin with. I added some tests
> and
> > fixed the issues.
> > 
> > The null embedding has been fixed by an additional loop doing a replace. It
is
> > still faster this way. I gathered some data. Using WriteAscii on a cons with
> > length 2^28 and 28 levels, the old version takes 1780ms, the new version
takes
> > 1140ms. When using WriteAscii on a cons with length 2^8 and 8 levels a total
> of
> > 2^20 times, the old version takes 1700ms, the new version takes 990ms.
> 
> *gentle nudge*

Ping on this.  This fast path would improve some things for nodejs.

The effectiveness of this patch can be tested with this, appended to test-api.cc

==================
#include <ctime>

TEST(ConsWrite) {
  v8::HandleScope scope;
  LocalContext env;
  v8::Local<v8::Value> result;
  const char* cons = "c = 'a'; for (var i=0; i < 28; i++) c = c+c;";

  v8::Local<v8::String> string = v8::String::Cast(*CompileRun(cons));

  char* buffer = new char[1 << 28];
  clock_t start = clock();
  string->WriteAscii(buffer, 0, (1 << 28) -1);
  clock_t stop = clock();
  printf("%f milliseconds\n", (double) (stop - start) / CLOCKS_PER_SEC * 1000);

  start = clock();
  string->WriteAscii(buffer, 0, (1 << 28) -1,
                     v8::String::HINT_MANY_WRITES_EXPECTED);
  stop = clock();
  printf("%f milliseconds\n", (double) (stop - start) / CLOCKS_PER_SEC * 1000);
}
==================

The result I get is
- w/o patch

1780.000000 milliseconds
1550.000000 milliseconds

- w/ patch

1180.000000 milliseconds
1220.000000 milliseconds