Report 20260512

Tester: Vseslav Levchenko

Hardware:

  • CPU model: AMD Ryzen 7 6800H with Radeon Graphics
  • CPU clock speed: 4.79 GHz
  • CPU number of cores/threads: 8 cores / 16 threads
  • CPU architecture: x86_64
  • Installed RAM: 15G
  • GPU: Rembrandt [Radeon 680M]; GA104M [GeForce RTX 3070 Mobile / Max-Q]
  • Operating system: Ubuntu 24.04.4 LTS

MEM-01 - Load Empty Map Baseline

MetricValue
JS Heap Used18297352 bytes (~18.3 MB)
Memory used in browser tab250 MB
Load stabilityStable

MEM-02 - Load Map With 100 Plantings

MetricValue
JS Heap Used21133032 bytes (~21.2 MB)
Memory used in browser tab300 MB
Load stabilityStable

MEM-03 - Load Map With 500 Plantings

MetricValue
JS Heap Used25961872 bytes (~26 MB)
Memory used in browser tab350 MB
Load stabilityStable

MEM-04 - Load Map With 1000 Plantings

MetricValue
JS Heap Used32399296 bytes (~32.4 MB)
Memory used in browser tab400 MB
Load stabilityStable

MEM-05 - Load Map With 5000 Plantings

MetricValue
JS Heap Used35425416 bytes (~35.4 MB)
Memory used in browser tab460 MB
Load stabilityStable

MEM-06 - Switch From Large Map To Empty Map

MetricValue
JS Heap Before Switch33325416 bytes (~33.3 MB)
JS Heap After Switch19811392 bytes (~19.8 MB)
Browser Memory Before Switch450 MB
Browser Memory After Switch270 MB
Observed Retention BehaviorNone

MEM-07 - Continuous Editing Session Over One Hour

MetricValue
JS Heap Growth~+5 to +15 MB / hour
Browser Tab Memory Growth~+30 to +120 MB / hour
Load stabilityStable

Conclusion

Memory

General

No significant memory-related issues were found.

Growth of memory usage is proportional to increase of object amount.

No common memory leak behavior was recorded.

JS heap usage increases gradually and remains low overall, indicating efficient JavaScript memory handling.

Browser tab memory increases more noticeably than JS heap, suggesting that rendering-related resources are the primary contributors to total memory usage.

Continuous editing

The observed gradual memory growth during the long editing session may indicate retained browser or application state even when no additional plantings are created.

Possible contributors include:

  • undo/redo history accumulation
  • browser rendering caches
  • delayed or non-deterministic garbage collection behavior in Firefox

However, the growth remained relatively slow during the one hour observation period and did not result in instability, excessive CPU usage, progressive slowdown, or crashes.

Because memory usage did not continuously accelerate and major memory was released correctly during the map switching test, the results do not indicate a severe or obvious leak.

The gradual increase observed during continuous editing sessions may still warrant additional long-duration profiling and heap snapshot comparison in future investigations.

Conclusion

Overall, behavior and performance appears to be normal for a map-heavy, React-based web app with a large codebase.

Hardware

The memory investigation did not indicate that PermaplanT is limited by JavaScript heap size or available CPU resources during map loading and idle usage.

However, this investigation did not specifically evaluate viewport interaction performance.

Separate observations during rapid panning of large maps suggest that some interactive workflows may become CPU-bound, as indicated by high CPU utilization and frequent Firefox profiler jank markers.

Additional performance-focused profiling should be conducted to investigate rendering and interaction performance independently from memory behavior.

Map sizeRecommended RAMCPUGPU
Small (10-100 plantings)4 GBAny modern dual-coreIntegrated GPU
Medium (100-500 plantings)8 GB4+ coresIntegrated or low-end dedicated GPU
Large (1000 plantings)8-12 GB4-8 coresModern integrated GPU or dedicated GPU
Very large (5000+ plantings)16 GB6-8+ coresDedicated GPU recommended (or strong integrated GPU)