Here is an analysis of CardDeck (related with #1848 as table rows should be rendered via Views and not with cloned template) performance with many Cards:

• performance of atk4/data is top notch (entity is iterated/loaded much faster then one Card is added/rendered)
• 1 Card /wo any executor takes ~0.6 ms to add/render
• there is no single significant bottleneck, but large part of the time is spent in templating, as each Card consists of several Views, each with ~20 template tag tree children
• adding a Card executor is slow
  • CardDeck::setMdel() calls Card::addClickAction
  • creating/rendering executor trigger button is ok, it takes ~0.1 ms / single (one UA) button
  • which calls Button::on with atk4/data UserAction
  • an executor is created here:

there are two problems:

1. ExecutorFactory::createExecutor() creating executor itself is quite slow (~0.4 ms / single (one UA) executor), it cannot be significantly optimized, the only solution is to create an executor for a model once and share/deduplicate it for all entities (table rows, Cards, ...)

2. ModalExecutor::executeModelAction() executor should not be initialized/rendered until needed/triggered (Modal executor should (re)load whole modal incl. buttons #1928, ~1.0 ms / single (one UA) executor)

(3. also each executor (currently/with point 1 and 2) takes quite a lot of memory (~50 KB / single (one UA) executor) and significantly increase the total rendered html/js size (~4 KB / single (one UA) executor))

the good new is, at least in Card::addClickAction(), executor is created from model (not entity) atk4/data UA, ID is passed as 1st $default arg - so point 1 should be doable /wo heavy refactoring

given the need to share/deduplicate UA executors in atk4/ui at least, we should aim to support model (not entity) atk4/data UA and maybe even drop entity (not model) atk4/data UA completely in the future