perf(ecs): per-frame copies, allocations and WASM crossings in run_systems and the zippers

Abierto
  • ¿Algo no está bien?
#493 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp, wasm
Área
game-dev, performance

Línea de trabajo

Read modules/ecs/wasm/Registry.hpp around lines 260–262 and 302–322 to trace run_systems and getZipper. First establish an e2e game performance measurement, since the issue says none has been taken. Compare the per-frame allocations and WASM crossings before and after the proposed caching and length-read changes; done means measured improvement without changing ECS behavior.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement modules:ecs
Which package or utils is this feature request for?

ecs

Feature

The hottest path breaks the repo's rule against per-frame allocation, at a cost of entities × systems. Every frame copies the systems vector and creates a shared_from_this() JS wrapper per system. Each getZipper builds a std::map, a JS array and one JS object per matching entity, calls get_js_class_name twice per component (3–6 JS property reads each) and re-reads comps["length"] on each iteration. No measurement was taken yet.

Where:

Evidence:

std::vector<emscripten::val> systems_copy = _systems;
for (emscripten::val &system : systems_copy)
    system(shared_from_this(), ctx);
Ideal solution or implementation

Copy the systems only when they change during a run, cache the class-name → array pointer lookup per constructor, and read length once. Measure before and after with the e2e game.

Alternative solutions or implementations

No response

Other context

Found during a code audit of main at be72076.

Lenguaje dominante
TypeScript
Estrellas
7
Forks
2
Merge medio
1 d 17 h
PR fusionados (30 d)
17

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NanoForge-dev/Engine

Todos los issues de NanoForge-dev/Engine

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.