[CONTEDIT-108] Improve block rendering performance Created: 08/May/17 Updated: 15/May/17 Resolved: 08/May/17 |
|
| Status: | Closed |
| Project: | Content Editor |
| Component/s: | None |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.0.4 |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Aleksandr Pchelintcev | Assignee: | Aleksandr Pchelintcev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Template: |
|
||||
| Acceptance criteria: |
Empty
|
||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||
| Sprint: | Basel 95 | ||||
| Story Points: | 5 | ||||
| Description |
|
As the linked investigation has illustrated definition resolution impacts the block rendering performance. What is worse the impact grows linearly depending on the registered block definitions amount. The reason for such slow down is the method of locating the related block definition: it is done by iterating over all the available block defs and comparing their {{type Instead we could simply fetch the block def via Registry#getProvider(strId) since for blocks type == name == id. This reduces the general overhead and also makes it independent from the block types amount (boils down to hashmap look-up). |