"Martin v. Loewis" wrote: > > > BTW, is the memory burden really such a big argument these days ? > > You should consider that malloc overhead is often 16 bytes per > object. Given that PyUnicodeObject is 24 bytes in 2.2, system malloc > will allocate 48 bytes per Unicode object on modern architectures. I > would think 100% overhead *is* a big argument. > > If you relate this to the actual data, it gets worse: A Unicode string > of length 1 would still require 32 bytes on an allocator that aligns > to 16. Therefore, to store 2 bytes of real data, you need 80 bytes of > memory. > > I don't know how much overhead pymalloc adds, though; I believe it is > significantly less expensive. Oh, I wasn't arguing against using pymalloc :-) I only think that nowadays, the trade-off "more flexibility vs. memory consumption" leans more towards the former than the latter. Not only because memory is cheap, but also because more flexibility tends to result in use of better algorithms and these can lead to better overall performance and lower total memory use. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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