penkovsky_sa/cherrypick
1
0
Fork 0
mirror of https://github.com/pese-git/cherrypick.git synced 2026-01-23 21:13:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(perf): clarify Map-based resolver optimization applies since v3.0.0 in all docs

Browse Source
This commit is contained in:
Sergey Penkovsky
2025-08-06 08:29:00 +03:00
parent 52a55219ab
commit 05cfca5977
3 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
cherrypick/README.md
View File

@@ -97,7 +97,7 @@ final dataBloc = await subScope.resolveAsync<DataBloc>();
### Fast Dependency Lookup (Performance Improvement)
> **Performance Note:**
> As of the latest version, CherryPick uses a Map-based resolver index for dependency lookup. This means calls to `resolve<T>()` and related methods are now O(1) operations, regardless of the number of modules or bindings in your scope. Previously, the library had to iterate over all modules and bindings to locate the requested dependency, which could impact performance as your project grew.
> **Starting from version 3.0.0**, CherryPick uses a Map-based resolver index for dependency lookup. This means calls to `resolve<T>()` and related methods are now O(1) operations, regardless of the number of modules or bindings in your scope. Previously, the library had to iterate over all modules and bindings to locate the requested dependency, which could impact performance as your project grew.
>
> This optimization is internal and does not change any library APIs or usage patterns, but it significantly improves resolution speed in larger applications.

2
doc/full_tutorial_en.md
View File

@@ -180,7 +180,7 @@ final service = scope.tryResolve<OptionalService>(); // returns null if not exis
### Fast Dependency Lookup (Performance Improvement)
> **Performance Note:**
> As of the latest version, CherryPick uses a Map-based resolver index for dependency lookup. This means calls to `resolve<T>()`, `tryResolve<T>()` and similar methods are now O(1) operations, regardless of the number of modules or bindings within your scope. Previously it would iterate over all modules and bindings, which could reduce performance as your project grew. This optimization is internal and does not affect the public API or usage patterns, but significantly improves resolution speed for larger applications.
> **Starting from version 3.0.0**, CherryPick uses a Map-based resolver index for dependency lookup. This means calls to `resolve<T>()`, `tryResolve<T>()` and similar methods are now O(1) operations, regardless of the number of modules or bindings within your scope. Previously it would iterate over all modules and bindings, which could reduce performance as your project grew. This optimization is internal and does not affect the public API or usage patterns, but significantly improves resolution speed for larger applications.
---

2
doc/full_tutorial_ru.md
View File

@@ -181,7 +181,7 @@ final service = scope.tryResolve<OptionalService>(); // вернет null, ес
### Быстрый поиск зависимостей (Performance Improvement)
> **Примечание по производительности:**
> В последних версиях CherryPick для поиска зависимости внутри scope используется Map-индекс. Благодаря этому методы `resolve<T>()`, `tryResolve<T>()` и аналогичные теперь работают за O(1), независимо от количества модулей и биндингов в вашем проекте. Ранее для поиска приходилось перебирать весь список вручную, что могло замедлять работу крупных приложений. Это внутреннее улучшение не меняет внешнего API или паттернов использования, но заметно ускоряет разрешение зависимостей на больших проектах.
> Начиная с версии **3.0.0**, CherryPick для поиска зависимости внутри scope использует Map-индекс. Благодаря этому методы `resolve<T>()`, `tryResolve<T>()` и аналогичные теперь работают за O(1), независимо от количества модулей и биндингов в вашем проекте. Ранее для поиска приходилось перебирать весь список вручную, что могло замедлять работу крупных приложений. Это внутреннее улучшение не меняет внешнего API или паттернов использования, но заметно ускоряет разрешение зависимостей на больших проектах.
---