[Aahz] > So in other words, we might as well go ahead and trade space for > speed? And simplicity, yes. The current scheme is delicate and obscure as well as slow and compact. Worse, it's grown hairier over the years as more platform-specific cases of extremely bad performance were reported, and an obscure scheme that grows more obscure over time is (IMO) a loser. > If someone really does have a million small lists, they're > probably mutating some of them constantly (or they'd use tuples). I don't know about that one -- "head arguments" in either direction are too easy to make up here. Since my employer mostly runs Linux, and adding a 4- byte list header field under gcc won't make any difference to total allocation, nobody's gonna hit me if it happens. Hell, I'd be happy to rip out the irritating union-with-long-double gc header trick that forces worse results under MSVC too (same thing: an increase in beauty without personal pain).
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