How fast can browsers process base64 data?
Posted by mfiguiere 11 days ago
Comments
Comment by adzm 4 days ago
Looks like this was brought up there as a result of this article too, which is neat! And helpful since I was just messing with a node script that is heavily decoding base64
Comment by Neywiny 4 days ago
Comment by Retr0id 4 days ago
Wow, finally! I've had to work around this so many times in the past (btoa/atob do not play nicely with raw binary data - although there are workarounds on the decode path involving generating data URIs)
Comment by rezmason 4 days ago
precision highp float;
uniform vec2 size;
uniform sampler2D src,tab;
void main(){
vec4 a=(gl_FragCoord-.5)*3.,i=vec4(0,1,2,0)+a.y*size.x+a.x,y=floor(i/size.x),x=i-y*size.x;
#define s(n)texture2D(src,vec2(x[n],y[n])/size)[0]
#define e(n)texture2D(tab,vec2(a[n],0))[0]
a=vec4(s(0),s(1),s(2),0)*255.*pow(vec4(2),-vec4(2,4,6,0)),a=fract(a).wxyz+floor(a)/64.,gl_FragColor=vec4(e(0),e(1),e(2),e(3));
}Comment by lioeters 4 days ago
Bravo, that is a thing of beauty.
Comment by pixelpoet 3 days ago
Another post in this thread mentioned V8 sped this up by removing a buffer copy; this is adding two buffer copies, each about an order of magnitude slower.
Come on guys...
Comment by rezmason 1 day ago
Comment by pixelpoet 22 hours ago
Web browser in a shader also sounds extremely inefficient, for obvious fundamental reasons.
Comment by rezmason 10 hours ago
The GLSL I originally posted is from the "cursed mode" of my side project, and I use it to produce a data URI of every frame, 15 times per second, as a twisted homage to old hardware. (No, I didn't use AI :P )
https://github.com/Rezmason/excel_97_egg
That said, is `pow(vec4(2),-vec4(2,4,6,0))` really so bad? I figured it'd be replaced with `vec4(0.25, 0.0625, 0.015625, 1.0)`.
Comment by alain94040 4 days ago
Comment by Retr0id 4 days ago
Comment by conradfr 4 days ago
Comment by skylurk 4 days ago
Comment by conradfr 4 days ago
Now that I think of it I should have cached the base64 in ETS to be even faster :)
Comment by tasn 4 days ago
Comment by adzm 4 days ago
Big performance wins recently optimizing some core operations:
https://bugzilla.mozilla.org/show_bug.cgi?id=1994067 https://bugzilla.mozilla.org/show_bug.cgi?id=1995626
which brings it near chrome performance without the new v8 optimizations.
Still more work to do, including avoiding extra copies just like v8, and exploring more simd etc. Generic slow items for toBase64 and fromBase64: https://bugzilla.mozilla.org/show_bug.cgi?id=2003299 https://bugzilla.mozilla.org/show_bug.cgi?id=2003305
extra copying of results: https://bugzilla.mozilla.org/show_bug.cgi?id=2003461 https://bugzilla.mozilla.org/show_bug.cgi?id=1996197
No reason all browsers would not be able to be similar in performance eventually. Pleased this was noticed and being worked on by both v8 and Firefox team
Comment by tasn 4 days ago
Incredible that FF is even slower than a JS only implementation running in FF.
Comment by jeffbee 4 days ago
Comment by tasn 4 days ago
I wonder if this is why Firefox feels so sluggish with some more complex SPAs.
Comment by zenethian 4 days ago
Comment by danhau 11 days ago
This had me scratching my head. Why would a base64 decoder need to skip spaces? But indeed, MDN documents this behavior:
> Note that: The whitespace in the space is ignored.
JS never ceases to surprise. Also, check out that typo :D
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Comment by wvbdmp 4 days ago
Comment by layer8 4 days ago
Comment by cluckindan 10 days ago
Comment by recursive 4 days ago
Comment by sigseg1v 4 days ago
Comment by moomoo11 4 days ago
Base64 isn’t obfuscation or encryption.