Skip to content

Add a page detailing the time complexity of operations on built-in types#154363

Open
StanFromIreland wants to merge 4 commits into
python:mainfrom
StanFromIreland:timecomplexity-doc
Open

Add a page detailing the time complexity of operations on built-in types#154363
StanFromIreland wants to merge 4 commits into
python:mainfrom
StanFromIreland:timecomplexity-doc

Conversation

@StanFromIreland

Copy link
Copy Markdown
Member

Inspired by @nedbat's post on Discourse:

One page in the wiki that I think should be in the docs is Time Complexity. It seems like important information about CPython and should be documented.

The page's location isn't ideal, but we don't have a better place for it currently. We discussed this at the last Docs Community meeting, but didn't come up with a better place to put it, and creating new top level sections is in my opinion, out of scope (as we'd need to move other pages as well). If it's desired we can do it in a future PR.

I spend a while considering how to best present time complexity here, avoiding complexity ;-) The wiki pages splits it into amortised, worst, best and averages cases (each type had a selection of those), but I think that it would be too confusing for readers. As such I give the average case, and put the details in the prose/footnotes.

The numbers are, hopefully, correct, as I don't think I missed any quirks (at least I don't know of any ;-). But I'd appreciate a review from the experts here, maybe Serhiy or Tim could please take a peek?

@read-the-docs-community

Copy link
Copy Markdown

Documentation build overview

📚 cpython-previews | 🛠️ Build #33688875 | 📁 Comparing 64fb553 against main (bfd774d)

  🔍 Preview build  

7 files changed · + 1 added · ± 6 modified

+ Added

± Modified

@picnixz picnixz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Iteration is, AFAICT, always O(n) so we can group that under a common table. Likewise, getting the length of a sized object is O(1).

I think it's better to keep pythonic exmaples as well. "d[key]" is mucher better than "get item" IMO.

When I read "the non-mtating operations below", it also rings "the opertaions below are all non-mutating". Instead, I suggest to add some * if the opertaion is mutating and explain that at the beginning of the document.

Comment thread Doc/library/time-complexity.rst
Comment thread Doc/library/time-complexity.rst
Comment thread Doc/library/time-complexity.rst
- *O*\ (*n*)
* - Get item
- *O*\ (1)
* - Set item [1]_

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Set item is a mutating operation.

- *O*\ (1)
* - Set item [1]_
- *O*\ (1)
* - Delete item

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deletion as well

Comment thread Doc/library/time-complexity.rst
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

3 participants