Kamuela_iOS: basically.

Shira: I’m just making it look nice

Grunin: I love me some jQuery on most projects, but micro-optimization while loading a giant library you aren’t using probably half of definitely seems to not add up

Feerick: I also just looked through the jDataView source and can pretty much guarantee that any cycles you save in that code which seriously, would be 0 cycles, are going to be dwarfed by the overhead of the calls into it

Shahid: And removing some mostly empty lines

Pander: I hate mostly empty lines

Rizor: Wrapped ***ignment operators like that can be easy to miss for unfamiliar people reading the code

Rizor: But hey, do what you gotta do

Feerick: Not to mention you’ll just have to move it out later when you need to do something else to it

Stowe: Well I don’t care about ppl who don’t know JS 😛

Feerick: Its more that that’s pretyt obscure code

Feerick: You even said, understanding it requires you know that xor is either 0 or -1

Dung: Tcsc, how often do you add things to a decompression algorithm from the ’90s?

Feerick: Well, if this is used in a hot path, you’ll sure as **** want to change out jDataView for something saner

Feerick: Probably at least once

Sweeny: I even put the labels from the ***embly code in comments, so that it can be easily compared to the original ***embly

Woodson: Tcsc, if I ever change it somehow, I’ll change it into a plain DataView

Feerick: Just jesus, https://github.com/jDataView/jDataView/blob/master/src/jdataview.js the amount of concatenating strings to build method names in here is awful.

Feerick: Also there are complex float deserialization code when you could just use a Float32Array with the same backing buffer

Conch: Good thing I don’t have to deal with floats

Feerick: The same is true for uint32 but the code isnt as complex.

Feerick: It still allocates a 4 element uint8array with every read

Feerick: Which is just like holy **** terrible

Feerick: The code you posted was awful

Feerick: Don’t write code like that.

Comegys: And this is why I don’t post code when tcsc is here

Feerick: Kamuela_iOS: the code in question was if xor { out.writeUint32last = ac; } else { out.writeUint32ac; }; vs out.writeUint32last = last & xor ac;

Feerick: Sorry if i’m too mean though

Bascom: Tcsc, I’d do the latter in ***embly

Wasyliszyn: Branching is expensive

Telega: Oh btw, https://github.com/jDataView/jDataView/issues/69

Veltin: We’ll see where that goes

Feerick: Branching is only expensive if its mispredicted and you’re talking a stall of like 20 cycles

Feerick: Which is like, nothing compared to a cache miss, which is likely in the code you’re calling into

Luchesi: Tcsc, well it’s expensive on an 8086. 😛

Suter: That looks like something I would encounter tcsc when having imposter syndrome recurring nightmares

Feerick: Kamuela_iOS: ha, i do a lot of bitwise math but i never ***ign in parameters. my code is usually pretty boring to look at. i have a few bad habits i’m trying to stop doing though

Gossin: Tcsc, I’m the kind of person who “well so this feature exists, let’s see how we can abuse it”

Okajima: Bitwise for the performance gain?

Feerick: Mostly due to color manipulation

Niksich: Basically like how do I rewrite this algorithm to be more machine native?

Feerick: More like aa 24 bb 16 gg 8 rr

Feerick: To build a pixel value

Feerick: I alos have a lot of 0 and 0 for coersion to int/uint but thats part of those bad habits i was mentioning

Bieberle: Don’t understand all the matrix codes :

Feerick: Kamuela_iOS: basically colors in pixels are stored as 32 bit numbers