Added Library-Convert label.

Added Triaged label.

Added Area-Library label.

Set owner to @Skabet.
Added Started label.

Proposed CL: https://codereview.chromium.org/208693008/

This comment was originally written by @tatumizer

fixing LATIN1 only doesn't help much, because people mechanically specify UTF8 as encoding.
You can implement very efficient test for UTF8 and ASCII using the following idea
bool isOneByteString(charCodes) {
  // charCodes is any list of ints
  for (int i=0, j=charCodes.length-1; i<=j; i++, j--) {
      int e = charCodes[i], f = charCodes[j];
      // without explicit check for type, it becomes slower, for some reason
      if (e is! int || f is! int) throw new ArgumentError();
      if ((e|f|255)!=255) return false;
  }
  return true;
}
Constant 255 is good for LATIN1 (which you don't need). For UTF8 and ASCII it's obviously 127
This kind of unrolling leads to good performance improvement, so you can test your data at the cost of approx. 1 nanosecond per char

About LATIN1, I don't agree:

• Fixing stuff always helps :)
• LATIN1 is default for HTTP, thus a lot of ASCII bodies are sent as such.

As for the other encodings, they are already implemented using a quite optimized, and somewhat similar, strategy - though the number of features we support adds a bit of overhead.

You are of cause more than welcome to propose patches, if you find ways to optimize the code!

Cheers,

Anders

This comment was originally written by @tatumizer

Look at benchmarks I included in the bug report: they are horrible! will they be the same after the fix for UTF8? These results show no trace of fast track for all ASCII chars. Fast track should kick in right away, until proven wrong. Benchmarks show more work is needed there. Up to you though. There'are sites that compare performance, people look into them, and dart will not have good showing there, and not because compiler is slow.

This comment was originally written by @tatumizer

Also, your remark about LATIN1 being default misses one point: people don't know about it. Go to any example on Internet (e.g. on stackoverflow) - my bet that 99% of then spefify UTF8 explicitly, no matter what language. People just copy these examples without thinking. Why create another performance pitfall, for no reason?
Again, it's not that I stand to gain personally from any of those changes, but I kinda like the language. Good performance will be a good selling point. Bad performance will be ridiculed.
Never mind.

I think there may be some misunderstandings here.

I absolutely acknowledge that the issue is valid and that performance is very bad here. About Latin1; I'm in no way advocating the usage of Latin1. However, if you don't copy code, and write a simple HTTP server yourself, it's very likely that the encoding will be Latin1. And the user should not be punished by bad performance, by simply not considering encodings.

Now, the proposed CL does not only improve Latin1, but also ASCII and UTF8, by a factor of 2x-3x in the case of pure ASCII characters, as far as I remember. This is not the only thing that can be improved here, and the issue should not be closed until the performance is as expected; very fast.

This comment was originally written by @tatumizer

by factor of 2x-3x? then it's ok. Not OK, but ok.
You can gain extra performance by implementing the meet-in-the-middle unrolling I sent earlier, it utilizes pipelining better,
Similar kind of unrolling can be used in other, and helps uniformly. I tested on 32-bit Windows.
Thanks anyway.

There are no other obvious fixes for the current implementation. A believe a much more thoroughly rewrite is needed to further improve the performance.

Removed the owner.
Added Triaged label.

This comment was originally written by @tatumizer

That's fine, it works much faster now; in one case (ASCII) even as good as
java, it's unrealistic to do everything in a single hop anyway,
Thanks!

Sounds like the performance has reached an acceptable level.

Added Fixed label.

This comment was originally written by @tatumizer

Yes, the overhead is reduced to minimum now.
LATIN1: chunks: 3973, time: 352
UTF8: chunks: 3973, time: 490
ASCII: chunks: 3973, time: 352
no transform at all: chunks: 3973, time: 274

(tested on file containing ASCII only).