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