Replace DataView.getUint8 by typed array access

[letmaik]

Using DataView is currently still slower than directly accessing a typed array. For the case of the expression dataView.getUint8(offset) it is possible to circumvent the use of DataView and directly use a typed array. This is possible since the DataView is initialized with a 1 byte element length, which makes it equivalent to a direct Uint8Array view of the data.

With this change, there are speed increases of 15% on Chrome 47 and 36% on Firefox 42 on my machine while decoding around 200MiB of data. Testing was done with a very large array of numbers where one third of elements were nulls.

I am working with such big data, so I would be happy if this is merged. Typically the data I have compresses extremely well (60MiB get down to 2MiB after gzipping in my case) so the bottleneck is the CBOR decoding after the data is unzipped. And this change is one step in making cbor-js a bit faster.

Test code:

var data = new Array(1024*1024*25) //*8 ~ 200MiB
for (var i=0; i<data.length; i++) {
  data[i] = i % 3 === 0 ? null : i + 0.1
}
var obj = {
  data: data
}  
var cborData = CBOR.encode(obj)

var runs = 3
var t0 = new Date()
for (var i=0; i<runs; i++) {
  CBOR.decode(cborData)
}
console.log((new Date()-t0)/runs + 'ms')

[paroga]

Sorry for the very very long silence. Does this change still make sense? Would a similar change for 16bit/32bit values increase the performance too?

[coveralls]

Coverage increased (+0.003%) to 99.265% when pulling 46cd936 on letmaik:uint8-optimize into 66ccfe3 on paroga:master.

[letmaik]

I just merged in the latest changes from master and repeated the benchmarks. The speed increases are still in the same ranges on both Firefox (48) and Chrome (52). Therefore I would still think that it makes sense. You cannot do the same optimization on the other data types as you wouldn't easily know the correct offset into the typed array view.

[TYoung86]

@paroga This change couldn't apply precisely to 16-bit and 32-bit values as the alignments would vary, 16-bit and 32-bit values are packed unaligned with their 8-bit prefixes, but an alignment check could be added before attempting a read; though the alignment check could offset the benefit of just using the DataView. The abundance of single-byte reads is easy enough to warrant this change.

[TYoung86]

@letmaik encoding, writeUint8, and writeUint8Array could likely benefit from this tweak

[letmaik]

This is getting old. Please merge it or I'll close the PR as I'd like to delete my fork of cbor-js.