Skip to content

Reduce memory footprint of SDK by separating namespace imports #269

Open
@samschott

Description

@samschott

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions