Brandt Bucher <brandtbuc...@gmail.com> added the comment:
Interesting idea! > It is likely that programs will have more than 2**16 functions versions, but > it is much less likely that they will have more than 2**16 versions of > special methods. Is it? The pyperformance suite isn't exactly representative of huge production apps, sure, but the most recent specialization stats don't seem to indicate that we ever run out of versions. Do we have reason to believe that real-world code would benefit from this? These versions are only created for successful specializations in hot code (and we typically expect a high degree of stability thereafter), so I would think that in practice it's actually quite rare to bump the version after the first few are handed out. > We should partition the version space into 1-0xffff for use by special > methods and 0x1000+ for use by other methods. Typo? It seems like the ranges 0x0001-0xFFFF and 0x10000-0x1FFFF are closer to what you're describing here. If so: - Does this mean that it will now be impossible to specialize explicit calls to special methods, like "super().__init__()" or "object.__new__()"? - Why not just maintain two separate 16-bit version counters, instead of one 17-bit counter with two distinct regions? Or maybe you meant 0x0001-0x7FFF and 0x8000-0xFFFF? But then my concern would be that it essentially halves the number of "normal" functions that we can successfully specialize. If it's likely that more than 2**15 "normal" function versions will be used and unlikely that 2**15 special methods will be used, lots of the special method versions will remain unused long after we've exhausted the "normal" versions. Also, just to make sure we're on the same page: when you say "other methods", are you actually referring to "other functions"? It doesn't seem like there's a reason for this versioning to only apply to method objects, but maybe I'm missing something. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46097> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
