Reduce memory footprint of SDK by separating namespace imports
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Beginne mit der Überprüfung, wie das SDK derzeit seine Namespace-Module importiert, und achte dabei besonders auf die team- und team_log-Namespaces. Vergleiche separate Namespace-Imports mit Lazy Loading und betrachte eine reduzierte Speichernutzung, ohne das bestehende Verhalten des SDK zu beeinträchtigen, als Definition of Done.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Python
- Sterne
- 985
- Forks
- 334
- Ø Merge
- 7 Std. 7 Min.
- Gemergte PRs (30 T.)
- 10
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus dropbox/dropbox-sdk-python
-
question
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
dropbox/dropbox-sdk-python#585 · 4 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
dropbox/dropbox-sdk-python#491 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
dropbox/dropbox-sdk-python#482 · 1 Kommentar · 2 Reaktionen ·
Maintainer antworten meist innerhalb von 1 Tag
-
question
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
dropbox/dropbox-sdk-python#476 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 20/100
dropbox/dropbox-sdk-python#475 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in dropbox/dropbox-sdk-python
Ähnliche Issues
-
namespace operations
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 72/100
EclipseFdn/open-vsx.org#14043 ·
Maintainer antworten meist innerhalb von 1 Tag
-
netbox status: needs triage type: bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
netbox-community/netbox#23376 ·
Maintainer antworten meist innerhalb von 1 Tag
-
feedback simulation workshop
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
githubnext/gh-aw-workshop#4455 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Triage 🩺
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
Maintainer antworten meist innerhalb von 1 Tag
-
[BUG] Container scenario crashes without expected_recovery_time, kube DNS example uses retry_waitOffenneeds-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 77/100
krkn-chaos/krkn#1627 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag