Optimización de FCP/LCP mediante el almacenamiento en caché de búsquedas de módulos raw-view

lookupView-patch

Implementado ahora a través de Map en lugar de Array.

Tiempo dedicado al arranque de la aplicación en lookupView - para instancia de desarrollo:

Tiempo ahorrado: ~115 ms

Esto disminuye el tiempo dedicado dentro de appendOutletView de 1.083 ms a 946 ms - para instancia de desarrollo.


patch en helpers de handlebar crudos

Sí, en realidad es un copiar y pegar con un cambio: usar una comprobación económica para isPath.

      // reemplaza @ember/-internals/utils isPath
      // @see: https://github.com/emberjs/ember.js/blob/3537670c14883346e11e841fcb71333384fcbc87/packages/%40ember/-internals/metal/lib/path_cache.ts#L5-L7
      // @see: https://github.com/emberjs/ember.js/blob/255a0dd3c7de1187f4a2f61a97cf78bfff8f66a8/packages/%40ember/-internals/glimmer/lib/utils/bindings.ts#L70
      let isPath = context.indexOf('.') > -1;

Por ejemplo, renderTopicListItem finalmente activa muchas llamadas a _getPath (otros 50-100 ms que ahorrar):
Firefox Profiler (callstack filtrado a _getPath dentro de renderTopicListItem)

Quizás las llamadas costosas a _getPath sean algo a optimizar en Ember.js y no en Discourse.


Y echa un vistazo a Firefox Profiler para obtener información sobre la ejecución de JavaScript: