[Python-Dev] Re: Should set objects maintain insertion order too?
26.12.19 00:56, Tim Peters пише: - I don't have a theory for why dict build time is _so_ much higher than dict lookup time for the nasty keys. 1/2 of items were copied to a new hashtable when the dict grew up. 1/4 of items were copied twice. 1/8 of items were copied three times, etc. In average every item is copied 1 time, so the build time is twice the lookup time when the cost of lookup is dominated. But the lookup benchmarking includes the overhead of iterating Python loop, which is more significant for "good" keys, thus the lookup time is larger than the build time. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/J5BUQZQUHONX6R6GLD5ESH5XVWLP3INS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Python Documentation and AIX specifics - how to proceed?
First - best wishes all for a happy and healthy 2020! As my nickname implies - my primary means to contribute to Python is with regard to AIX. One of the things I recently came across is Misc/README.AIX which was last updated sometime between 2010 and 2014. I am thinking a facelift is in order. Assuming 2010-2011 as the original date - much has changed and many of the comments are no longer accurate. Before saying so, I would like to check here that - having all tests pass on the 3.8 bot implies that there are no outstanding issues. As to the historical issues in the current document - these could either be deleted, or a short text describing when they were resolved (e.g., Python 3.7, or just resolved, but noone knows exactly how or when - whether it was a Python change, or a platform (AIX) change. What I see as being more relevant is the description re: how to build Python for AIX - for the "do it youself"-ers. So, besides the direct question re: what to say about the old "known issues" and whether there are no known issues aka, no issues identified via the standard tests - I would appreciate feedback on what is considered appropriate - anno 2020 - for any Misc/README.platform text. Additionally, I am willing to work on other areas of the standard documentation where it is either needed or considered appropriate for platform specific details and/or examples. This is not something I would try to get done in a single PR, Instead I am thinking a single -longer term- issue - and multiple PR's to work through corrections and additions during 2020. Focus on Python 3.9 and beyond yet where appropriate backlevel to Python 3.8 or even 3.7. Sincerely, Michael signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/6BMGBUK4A54N56UOEE3OSXXU2TSU3MIN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
[Tim] >> - I don't have a theory for why dict build time is _so_ much higher >> than dict lookup time for the nasty keys. To be clearer, in context this was meant to be _compared to_ the situation for sets. These were the numbers: 11184810 nasty keys dict build 23.32 dict lookup 13.26 set build 9.79 set lookup8.46 Build time is higher than lookup time for both, which isn't surprising. But it's _much_ higher (whether in absolute or relative terms) for dicts than for sets. [Serhiy Storchaka ] > 1/2 of items were copied to a new hashtable when the dict grew up. 1/4 > of items were copied twice. 1/8 of items were copied three times, etc. > In average every item is copied 1 time, so the build time is twice the > lookup time when the cost of lookup is dominated. I agree the average total number of table insertions per element approaches 2 either way (counting insertions due to internal table growth as well as insertions visible from Python code). That's why it's expected that build time exceeds lookup time (the latter does exactly one lookup per element). > But the lookup benchmarking includes the overhead of iterating Python > loop, which is more significant for "good" keys, thus the lookup time is > larger than the build time. Iteration time is too minor to care much about. Even in the worst case (sets with the nasty keys), the Python: for k in d: pass takes under a second here. Take a full second off the "set lookup" time, and dict build time still exceeds dict lookup time (whether in absolute or relative terms) much more so than for sets. But I'm not going to pursue it. The high-order bit was just to demonstrate that the set object's more complicated (than dicts) probe sequence does buy highly significant speedups - in at least one highly contrived case. Since the probe sequence changes were aimed at reducing cache misses, a full account requires comparing cache misses between the dict and set implementations. That's a mess, and slogging through it appears unlikey to result in insight. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/IYPHUKW7DGYNAFAC4AOCDYYUWANHN5YE/ Code of Conduct: http://python.org/psf/codeofconduct/
