Reduce memory footprint of SDK by separating namespace imports
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reviewing how the SDK currently imports its namespace modules, paying particular attention to the team and team_log namespaces. Compare separate namespace imports with lazy loading, and treat reduced memory usage without breaking existing SDK behavior as the definition of done.
Written by the indexing model from the issue text.
Description
Why is this feature valuable to you? Does it solve a problem you're having?
The Dropbox API and SDK cover a large range of functionality while some apps only use a small subset. This may be particularly true for some namespaces such as team and team_log which require different Dropbox subscriptions.
Importing all modules to cover the full API requires a relatively large amount of memory (~30 MB without 3rd party modules such as requests). A large fraction of this actually comes from the team_log namespace.
Describe the solution you'd like
Would it be possible to have separate classes for different namespaces and import modules only as needed? This of course would be a major change in design and may deviate from how other Dropbox SDKs handle this. Nevertheless, it may be worth considering, especially as new namespaces to support an evolving product will be added in the future.
Describe alternatives you've considered
Lazy loading of modules, at the point of use, may be an alternative.
- Dominant language
- Python
- Stars
- 983
- Forks
- 331
- Avg merge
- 3m
- Merged PRs (30d)
- 10
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dropbox/dropbox-sdk-python
-
question
Difficulty 4/5 3-5 days Newbie friendliness 35/100
dropbox/dropbox-sdk-python#585 · 4 comments ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
dropbox/dropbox-sdk-python#491 · 1 comment ·
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 35/100
dropbox/dropbox-sdk-python#482 · 1 comment · 2 reactions ·
-
question
Difficulty 5/5 Over a week Newbie friendliness 25/100
dropbox/dropbox-sdk-python#476 · 3 comments ·
-
bug
Difficulty 5/5 Over a week Newbie friendliness 20/100
dropbox/dropbox-sdk-python#475 · 1 comment ·
All issues in dropbox/dropbox-sdk-python
Similar issues
-
essnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
[Feature] 奇物选择添加优先级 Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Giskard-AI/giskard-oss#2840 · 1 comment ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Openarea: repo bug perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yeti-platform/yeti#1380 ·