4 ms·

Interesting, but if someone else sees your code they wont know what is going on. Also, it only gives the right answer for positive numbers, its off by one on n

by bshep 16y ago

Interesting, but if someone else sees your code they wont know what is going on. Also, it only gives the right answer for positive numbers, its off by one on negative numbers.

BudVVeezer 16y ago
When I read about these sort of hacks to get performant JS code, it reminds me of how things used to be thirty years ago. Sacrifice code readability to get a speed increase because of poor tools...
- robin_reala 16y ago
  If you look at the comments you’ll see some test results. The slowest result was 38ms / 100,000 iterations. Even if you looked at that result on a mobile device it still wouldn’t be what you’d call unperformant. In other words, this is micro-optimisation at a pointless level.
  - BudVVeezer 16y ago
    I don't disagree with your point. I was speaking more towards the general trend. It seems like I see one of these articles every week or so.
  - Spikefu 16y ago
    Not necessarily. I just finished optimizing an AES implementation where some of the functions are called hundreds of thousands of times when decrypting a 300k payload. In cases like that, micro-optimization is not at all pointless unless you forget to benchmark the whole thing for each version and compare.
- axod 16y ago
  On my Chrome: Math.floor = 2224ms for 100,000,000 iterations 0| = 302ms for 100,000,000 iterations. So in terms of performace, the difference is moot. If you want hacky non readable code that sometimes works, use 0|
RiderOfGiraffes 16y ago
> ... if someone else sees your code > they won't know what is going on. The same is true of all idioms in a language. But when you see something you don't understand you work through it, see what's going on, acquire the idiom for yourself, and move on. I don't see that as a problem. If you're really worried about readability, wrap it in a macro. Only giving the same answer as floor for positive numbers need not be a problem - you just need to know that it will do what you want in the context you have. So often one uses "floor" because it gives the right answer, and not because it's actually "floor".
- kaddar 16y ago
  Maintenance costs are one of the highest costs of software engineering, so when the idioms are very diverse, and you are presented with a new idiom, the best choice is to minimize idioms by only using behaviors which are expectable. If performance is an issue, then use these obfuscating idioms, but only if you are able to abstract them well and maintain performance (as you suggest), or document them completely and concisely.
  - RiderOfGiraffes 16y ago
    I don't regard this idiom as being at all obfuscating. I agree that people who aren't comfortable in the language will find it jarring at first, and will slow them down, but I don't see this as a problematic example. There is a balance to achieve. This is one example, and arguing the specifics of this one example is not as useful as being able to make judgement calls in the wild, for real, and get most of the close enough to right. It's not exact. But idioms, per se, should not be rejected out of hand purely because they're unknown to you.
    - kaddar 16y ago
      Well, focus on writing code that maps to the english or pseudocode definition, and attempt to make the pseudocode definition as high level as possible, if your goal is to minimize maintenance costs. This idiom obfuscates, as you state yourself, because people who aren't comfortable with the language will find it jarring at first. I understand where you are coming from: If everyone knew it, it wouldn't be obfuscating. But I argue that people forget idioms or never learn idioms that don't map to our human explanations rather quickly, so it increases maintenance costs. I argue that in this case, it obfuscates simply because bitwise or'ing data is too low level and doesn't have a lot to do with rounding down without understanding the internal representation of the number.
tomkinstinch 16y ago
I completely agree about using floor() for readability. That said, could we fix the negative value issue as follows and still see performance benefits (don't have the time to test at the moment)? x = x < 0 ? (0|x) - 1 : 0|x; ---or maybe--- x |= 0; x = x < 0 ? x-1 : x; ---or possibly--- x |= 0; x = ((x ^ (x >> 31)) - (x >> 31)) - 1; If the above bitwise operation were wrapped in a helper function, would we still see any performance gain?

by bshep 16y ago

Interesting, but if someone else sees your code they wont know what is going on. Also, it only gives the right answer for positive numbers, its off by one on negative numbers.

BudVVeezer 16y ago

When I read about these sort of hacks to get performant JS code, it reminds me of how things used to be thirty years ago. Sacrifice code readability to get a speed increase because of poor tools...

robin_reala 16y ago
If you look at the comments you’ll see some test results. The slowest result was 38ms / 100,000 iterations. Even if you looked at that result on a mobile device it still wouldn’t be what you’d call unperformant. In other words, this is micro-optimisation at a pointless level.
- BudVVeezer 16y ago
  I don't disagree with your point. I was speaking more towards the general trend. It seems like I see one of these articles every week or so.
- Spikefu 16y ago
  Not necessarily. I just finished optimizing an AES implementation where some of the functions are called hundreds of thousands of times when decrypting a 300k payload. In cases like that, micro-optimization is not at all pointless unless you forget to benchmark the whole thing for each version and compare.
axod 16y ago
On my Chrome: Math.floor = 2224ms for 100,000,000 iterations 0| = 302ms for 100,000,000 iterations. So in terms of performace, the difference is moot. If you want hacky non readable code that sometimes works, use 0|

RiderOfGiraffes 16y ago

> ... if someone else sees your code > they won't know what is going on. The same is true of all idioms in a language. But when you see something you don't understand you work through it, see what's going on, acquire the idiom for yourself, and move on. I don't see that as a problem. If you're really worried about readability, wrap it in a macro. Only giving the same answer as floor for positive numbers need not be a problem - you just need to know that it will do what you want in the context you have. So often one uses "floor" because it gives the right answer, and not because it's actually "floor".

kaddar 16y ago
Maintenance costs are one of the highest costs of software engineering, so when the idioms are very diverse, and you are presented with a new idiom, the best choice is to minimize idioms by only using behaviors which are expectable. If performance is an issue, then use these obfuscating idioms, but only if you are able to abstract them well and maintain performance (as you suggest), or document them completely and concisely.
- RiderOfGiraffes 16y ago
  I don't regard this idiom as being at all obfuscating. I agree that people who aren't comfortable in the language will find it jarring at first, and will slow them down, but I don't see this as a problematic example. There is a balance to achieve. This is one example, and arguing the specifics of this one example is not as useful as being able to make judgement calls in the wild, for real, and get most of the close enough to right. It's not exact. But idioms, per se, should not be rejected out of hand purely because they're unknown to you.
  - kaddar 16y ago
    Well, focus on writing code that maps to the english or pseudocode definition, and attempt to make the pseudocode definition as high level as possible, if your goal is to minimize maintenance costs. This idiom obfuscates, as you state yourself, because people who aren't comfortable with the language will find it jarring at first. I understand where you are coming from: If everyone knew it, it wouldn't be obfuscating. But I argue that people forget idioms or never learn idioms that don't map to our human explanations rather quickly, so it increases maintenance costs. I argue that in this case, it obfuscates simply because bitwise or'ing data is too low level and doesn't have a lot to do with rounding down without understanding the internal representation of the number.

tomkinstinch 16y ago

I completely agree about using floor() for readability. That said, could we fix the negative value issue as follows and still see performance benefits (don't have the time to test at the moment)? x = x < 0 ? (0|x) - 1 : 0|x; ---or maybe--- x |= 0; x = x < 0 ? x-1 : x; ---or possibly--- x |= 0; x = ((x ^ (x >> 31)) - (x >> 31)) - 1; If the above bitwise operation were wrapped in a helper function, would we still see any performance gain?