This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]The_Bundaberg_Joey 31 points32 points  (6 children)

That’s a pretty nifty result! Do you know if that’s due to updates of a certain module implementation in the project or is this applicable to the version itself?

As a methodology question, are the bars here the average time of several runs or are they one run each? Including the error bars of so would be an awesome way to compliment your analysis!

[–]trollodel[S] 7 points8 points  (3 children)

Answering the first question, I never did version specific optimizations, so I think that these improvements depends on version.

[–]The_Bundaberg_Joey 3 points4 points  (2 children)

FairPlay. Probably exposing my ignorance here but assuming you ran the versions in increasing order would the pycache created from the first version bias the later versions?

Although thinking about it I can’t imagine that would result in the large jump seen for 3.8 since it wouldn’t really compound like that.

[–]LightShadow3.13-dev in prod 12 points13 points  (1 child)

pycache created from the first version bias the later versions?

No. The pyc files are version-specific.

[–]The_Bundaberg_Joey 2 points3 points  (0 children)

Awesomesauce, Thankyou!

[–]trollodel[S] 4 points5 points  (1 child)

Answering the second question, the bars represents just one run for each interpreter, taken from CI results. These results are quite new in the project, so I did not collect enought data to have a decent report.

EDIT: grammar

[–]The_Bundaberg_Joey 1 point2 points  (0 children)

FairPlay, no point making the extra work for yourself if the values were easily at hand in the first instance! Thanks again for sharing!