[Jim Fulton]
> ZODB has a TimeStamp type that uses a 32-bit unsigned integer
> to store year, month,, day, hour, and minute in a way that makes it dirt
> simple to extract a component.
You really think so? It's a mixed-radix scheme:
v=((((y-1900)*12+mo-1)*31+d-1)*24+h)*60+m;
so requires lots of expensive integer division and remainder operations to
pick apart again (the trend in CPUs is to make these relatively more
expensive, not less, and e.g. Itanium doesn't even have an integer division
instruction).
If we had this to do over again, I'd strongly suggest assigning 12 bits to
the year, 4 to the month, 5 each to day and hour, and 6 to the minute. The
components would then be truly dirt simple and dirt cheap to extract, and we
wouldn't even have to bother switching between 0-based and 1-based for the
months and days (let 'em stay 1-based). They would still sort and compare
correctly in packed format. The only downside I can see is that not
pursuing every last drop of potential compression would shrink the dynamic
range from 8000+ years to 4000+ years, but we're likely to have much worse
problems in Zope by the year 5900 anyway <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4