Request for Help with Scene Performance in Lattice Visualizer

[Max DeMarr]

Good evening, everyone,

I am currently working on this project:
Interactive Lattice Visualizer, an interactive lattice visualizer. While it is not yet ready for a GSDEMO submission, I hope to submit it once I’ve refined it further. However, I’m facing a major issue that I can’t resolve on my own and would greatly appreciate your help.

The Issue:
After multiple scene reloads, the looping and rendering of the scene slows to an unacceptable level. Each time the scene parameters (e.g., the number of nodes or lattice type) are changed, the active scene is deleted using scene.delete() and a new one is created. This process occurs around line 286 in my load_it() method. According to the documentation, scene.delete() should remove all objects in the canvas.

To reproduce this issue, try setting the number of nodes to 4000 a couple of times, then revert it to 40. You’ll notice that the performance of the 40-node lattice after these reloads is significantly worse than the performance of the initial 40-node lattice when the page first loads.

Possible Cause:
I suspect that while scene.delete() removes objects from the canvas, it doesn’t clean up all associated data, including pointers to objects stored in self.obj (from my Node class). If that’s the case, these stale pointers might accumulate in memory, numbering in the tens of thousands after repeated reloads, which could explain the stagnation. If this hypothesis is correct, I may need to explicitly clear or overwrite all nodes whenever I reload the lattice/scene.

Request for Help:
Does anyone have ideas on how to efficiently reload the scene and/or completely clear all stored data without requiring a manual page refresh?

Additionally, if you have any comments or suggestions regarding my code in general, I’d greatly appreciate your feedback!

Thank you in advance for your time and help!

Happy New Year

- Maximillian

[Bruce Sherwood]

I did set the number of nodes to 4000 several times, then reverted it to 40, and I didn't see any slowdown. Then I played with going back and forth between 40 and 4000 and never saw a slowdown. What computer and operating system are you using? What browser? Performance is much faster with Chrome or Edge than with other browsers.

As a practical matter, your program is way too big to make it feasible for someone else to debug it. Perhaps you could write a short program that illustrates the problem you observe.

Bruce

[Max DeMarr]

This is interesting. Based on your suggestion, I created a new program called Object Deletion Test, which simply loads a 4^3 cube of simple_sphere objects. Initially, after testing larger grid sizes and reloading numerous times with the scene.delete() method, I couldn’t detect any performance decrease compared to the very first render upon page or program loading.

This result was puzzling, so I incorporated the attach_arrow objects into the new test program. I use these attach_arrow objects to render node connections in my main Lattice program. After adding them to the test program, I was able to reproduce the performance drop I had originally observed after multiple reloads.

System Information:

• Device: Dell Inspiron 7580
• Processor: Intel i7-8565U CPU @ 1.80GHz (4 cores)
• Memory: 16 GB RAM
• Graphics: Intel UHD 620 and NVIDIA GeForce MX250
• OS: Windows 11
• Browser: Google Chrome (up-to-date)

I also tested the program on another machine and managed to replicate the behavior there as well.

Observations:

In the new Object Deletion Test, the performance degradation becomes noticeable under the following conditions:

1. Click the Enable Arrows button once.
2. Click the Reload button north of 10 times.

Each reload regenerates the 4^3 simple_sphere objects with attach_arrow connections. After 10 reloads, a drop in performance becomes apparent. By 20 reloads, the simulation appears to run at half speed.

Importantly, when performing the same actions without enabling the arrows, there is no noticeable drop in performance, even after numerous reloads.

Additional Notes:

I had intended to use the rendering tools to monitor updates per second and frame times (and possibly other metrics), but I’ve forgotten the syntax for enabling these tools. Unfortunately, I couldn’t find any relevant information in the documentation. If this feature is documented, I’d appreciate a pointer to the relevant section.

Thanks for the help,

-Maximillian

[Bruce Sherwood]

It's not documented, but see this program:

   https://www.glowscript.org/#/user/GlowScriptDemos/folder/Examples/program/RotatingCubes-VPython/edit

Bruce

[Bruce Sherwood]

I'm unable to perceive a slowdown, now matter how many times I click Reload.

Bruce

[Max DeMarr]

Here is a link to a screen recording I captured. https://drive.google.com/file/d/1TcxMuc47cqEB7IUhrejYvccIo6BGTRxv/view?usp=sharing. I show off the smoothness of the frame rate at the 6-second mark and then perform the reloads with the attach_arrow option enabled. At the 46-second mark, I reverted the dimensions and the options back to the starting conditions and observed a very choppy performance.

Here is a link to a different screen recording. https://drive.google.com/file/d/1QQjj_evJB5jwbi-aRyTy42gw08fPEjWw/view?usp=sharing. In this one, I do not enable the attach_arrows option initially and perform the same actions as I did in the first video. After roughly 20 reloads, I reverted the dimensions to the starting conditions and observed no change in frame smoothness. This is the performance behavior I would expect to see.

Thank you for the Demo link, I recall looking at that now. I tried implementing that into my testing program and it is viewable in the videos. I am unsure why it sometimes jumps to Infinity renders / s, but that might be a consequence of the scene.delete() interaction.

- Maximillian

[Bruce Sherwood]

Don't know whether this is relevant, but I'll comment that when I run 

   https://www.glowscript.org/#/user/GlowScriptDemos/folder/Examples/program/RotatingCubes-VPython

on my computer the displayed data are 55 renders/s * 0.7 ms/render = 40 rendering/s

What do you see?

Bruce

[Max DeMarr]

I achieve roughly 53 renders/s * 1.4 ms/render = 70 rendering/s

The 1.4 ms/render element is quite stable on my machine so it does seem there is some significance there. In addition, I do not have any other browsers open or any serious background tasks active that I can see.

- Maximillian

[Max DeMarr]

I wanted to document my solution for future readers of this thread who may encounter the same problem. In my original implementation, when reloading the scene with new parameters (such as the number of nodes or sphere objects), I would call the scene.delete() method, break my main while loop that updates the scene's objects, and then create a new scene with new objects. Over time, this approach led to performance issues after multiple reloads, especially during simulations with a high quantity of objects. Although this problem might not affect everyone, I wanted to resolve it.

Instead of relying on the scene.delete() method, I redesigned my classes and other methods to reuse the objects created in the scene. My solution eliminates the use of the scene.delete() method and instead "recycles" the objects within the scene. When certain objects are no longer needed (e.g., reducing the number of spheres), I set their visibility to False and remove them from my active list of objects. When increasing the number of objects, I retrieve the new objects from this list of previously recycled objects, before going to create new ones. Although I am only using simple spheres and cylinder edges, this approach has proven effective.

I tested and implemented this solution in the Object Deletion Test program mentioned above and subsequently integrated it into my main program. With this method, I observe no performance degradation, regardless of the number of scene reloads.

Best regards,
Maximillian