Hacker News Reader

Comment by frays | Hacker News Reader

The only reason I can think of is YYYYMMDDHHMM represented as an unsigned long is 4 bytes, while the equivalent in characters would require 12 bytes.

Is it possible that at Microsoft's scale this would actually make a significant difference?

View on HN

Anything you do will take 3x the memory, so yes... I cant see why anyone would store as a string internally, you have to decode into a number anyway so just extra work. Strings are only useful to humans.

Edit: reading all the comments here, I get the feeling high level programmers don't fully understand how things are represented at the low level, there is no purpose in storing a version/serial as a string.

There are lot of "numbers" not actually being numbers. E.g. phone "numbers" are not numbers. The same as a house "numbers" are not numbers. Version "numbers" are also often not numbers (e.g. 2.1.230-rc.1).

If the OP bug was really triggered by a string of numerical characters not fitting into a 32bit integer, all the trouble of saving a few bytes on the client system were not worth it.

Yes, that is what the OP of the thread said, I've read it. Version numbers can be numbers if you want, and plan them to be. Which is the case here, its not a string fit into a 32 bit integer, its actually an integer. But they didn't think to check the max size which would only fit in an unsigned. Its an odd choice on their part, but certainly would have worked.

This very much depends on the protocol. Microsoft loves XML and and if the update package has an XML manifest with update information attached to it, it's very well a string that gets serialized to a number. The same applies to JSON and other text-based formats.

And that is fine though because at some lower level everything becomes a number to a computer. I think everyone is getting hung up on this string/number difference; data from humans is going to come as a string, thats no reason to store or process it as such.

Plenty of data is stored in varied types for processing that are efficient for a computer, for example DNS has been using date-based serial numbers successfully for decades, and stored internally as uint32.

Re your edit: these days, most developers are web developers where people don't care about these optimizations.

It's a little silly that a test didn't catch this problem, but using a version number somewhere high up in the long makes total sense to me. After all, version numbers can be anything you define them to be, as long as they're unique. You'd like them to be sortable, but they don't even have to be.

Sorry, I edited twice (just for confusion hah).

I don't think it's that they don't care, I suspect many simply do not understand what is under the hood in the first place; and they don't need to when doing web development. The fact that some here suggest storing version as a string is some how faster and safer is a big give away.

Perhaps saying they don't care is a bit much, they usually just don't need to care. The data is delivered to most websites in the form of JSON which can be parsed to any data format you want, and at that point it might even be faster to do a string compare to skip the double/int conversion.

I got what you were saying. That certainly may be case, depending on application. It looks in this case like its just definition files being loaded into memory, and if they need to compare that version more than once, doing it as a single operation binary comparison will be significantly faster than continually comparing a UTF-8 string (SIMD aside)

It probably did, 25 years ago

Not likely. Modern software developers laugh this kind of difference away, and will almost always default to taking a memory/storage space hit over other possible trade-offs (performance, correctness, convenience...)

Considering storage/memory requirements for modern desktop/mobile apps, I wouldn't mind if developers would occasionally think about optimizing them.

Nah, we computer scientist are happy embedding electron into every application no matter how small.

Storing non-numeric data as strings is not what makes modern apps bloated. It's the technologies used (Electron) and a general “I don't care” approach.

Application developers not system engineers. People who work on high performance servers will always look to reduce overhead as much as possible.

a simple tuple of appropriately-sized integer types would only need 8 bytes, which coincidentally is what MS will need come 2043.

That does mean rolling your own "greater-than-or-equal" operation though.

Reply on news.ycombinator.com