[Guido] >>> - On the other hand, a list of ints takes half the memory (given that >>> most of those ints are not shared). [Tim] >> Isn't this 2/3 rather than 1/2? [yadda yadda] [Guido] > An int is currently 3 units: type, refcnt, value. (The sepcial int > allocator means that there's no malloc overhead.) A list item is one > unit. So a list of N ints is 4N units (+ overhead). In the proposed > scheme, there would be 2 units. That makes a factor of 1/2 for me... Well, if you count the refcount, sure <wink>. Moving on, implies you're not contemplating making the descriptor big enough to hold a float (else it would still be 4 units assuming natural alignment), in turn implying that *only* ints would get the space advantage in lists/tuples? Plus maybe special-casing the snot out of short strings? >> Well, Python already has homogeneous int lists (array.array), >> and while they save space they suffer in speed ... > Which would become faster with the proposed scheme since it would not > require any heap allocation (presuming 2-unit structs can be passed > around as function results). They can be in any std (even reasonable) C (or C++). If this gets serious, though, strongly suggest timing it on important compiler + platform combos, especially RISC. You can probably *count* on a PyObject* result getting returned in a register, but depressed C++ compiler jockeys have been known to treat struct/class returns via an unoptimized chain of copy constructors. Probably better to allocate "result space" in the caller and pass that via reference to the callee. With care, you can get the result written into its final resting place efficiently then, more efficiently than even a gonzo globally optimizing compiler could figure out (A calls B call C calls D, and A can tell D exactly where to store the result if it's explicit). >> [other ramifications for >> "i = j + k" >> ] > I though this was assumed all the time? Apparently it was! At least by you <wink>. Now by me too; no problem. >> [refcount-on-int drivel] > Don't get this -- there's no object on the heap to hold the refcnt. I don't get it either. Desperation? The idea that incref/decref may need to be treated as virtual methods (in order to exempt ints or other possible direct values) really disturbs me -- incref/decref happen *all* the time, explicit integer ops only some of the time. Turning incref/decref into indirected function calls doesn't sound promising at all. Injecting a test-branch guard via macro sounds faster but still icky, and especially if the set of exempt types isn't a singleton. no-positive-suggestions-just-grousing-ly y'rs - tim
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