class Buffer {
void addByte(int byte) ...
void writeByte(int byte, int index) ...
void getByte() ...
int readByte(int index) ...
void addInt32(int value) ...
void writeInt32(int value, int index) ...
void getInt32() ...
int readInt32(int index) ...
... etc for each type, including typed lists ...
}
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
########### Uint8 Uint8 List 0.09 Uint8 Data 0.13 40% slower########### Int32 Int32 List 0.15 Int32 Data 0.89 6x slower
########### Uint32 Uint32 List 0.23 Uint32 Data 0.99 4x slower
########### Uint32 NoCache Uint32 List NoCache 0.72 Uint32 Data NoCache 0.99 40% slower
########### Int64 Int64 List 7.82 Int64 Data 8.63 10% slower
########### Uint64 Uint64 List 4.09 Uint64 Data 5.30 30% slower
########### Uint64 NoCache Uint64 List NoCache 4.67 Uint64 Data NoCache 5.49 18% slower
########### Float32 Float32 List 0.25 Float32 Data 1.30 5x slower
########### Float32 NoCache Float32 List NoCache 0.71 Float32 Data NoCache 1.36 2x slower
########### Float64 Float64 List 0.23 Float64 Data 1.29 5-6x slower
########### Float64 NoCache Float64 List NoCache 0.71 Float64 Data NoCache 1.58 2.2x slower
The benchmarks are so "micro", they may not be relevant, but the conclusion still holds when encoding/decoding large chunks in production code.This is my take at a growable untyped buffer. There are probably a few mistakes.(Other libs in the package are still being refactored/merged from company code, so please ignore).
A native version of that would make my day and would probably be used by a lot of people on the server.
setXYZ() accepts optional endianess argument which defaults to BIG_ENDIAN so you are not doing exactly the same operations in both cases.
--
We have growable typed lists in package: typed_data, so we could consider having a growable bytedata as well. I'll file a feature request for it.
/L
Surprised me too, but in fact it is not optimized, for me the shift runs it faster.
Anyway, sure it will be addressed at some point, there's a lot of room left for the vm to bump in speed.
data[k] = j;
data[k + 1] = j >> 8;
data[k + 2] = j >> 16;
data[k + 3] = j >> 24;
This was fixed some time ago. Now ByteData performs fine, and it's faster (by almost a factor of 2) to use setInt32