4 ms·
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 pos
by frays 5y ago
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?
- pintxo 5y agoIt probably did, 25 years ago
- throwuxiytayq 5y agoNot 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...)
- watermelon0 5y agoConsidering storage/memory requirements for modern desktop/mobile apps, I wouldn't mind if developers would occasionally think about optimizing them.
- selfhifive 5y agoApplication developers not system engineers. People who work on high performance servers will always look to reduce overhead as much as possible.
- petee 5y agoAnything 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.
- foepys 5y agoThere 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.
- petee 5y agoYes, 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.
- foepys 5y agoThis 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.
- petee 5y agoAnd 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.
- yodelshady 5y agoa 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.