FPS debug

[nPellejero]

Hello, I am developing a model and visualization project that involves vehicles moving arround a city. The GPS graph of my city is used, and vehicles can travel to point A to point B and interact with each other. Is a simple model of traffic in a city. Visualization is done with a leaflet map, and D3.

The issue is that I am doing test with 500 - 1000 agents, and after a few minutes I note that the visualization slows down. My guess is that the front end is asking for get_step request less frequently that it should. It starts at 20 FPS, and after a few minutes, it seems to go like 5 FPS or so. (judging visually the speed of get_step requests, and visualization)

So, how can I debug this ? Can I meassure FPS from server and from front end? What other things could be happening?

I am running the model and visualization in Ubuntu 16.04 , mesa installed with conda, in a I5 processor.

Any help is appreciated.

Nicolas.

Thanks.

[Corvince]

Hi there,

Your model and visualisation sounds very interesting! Can you share some of it as an example of a more advanced model created with Mesa?

Regarding your question, here is how FPS actually work: after the get step message is sent, the server calculates the next step and sends the step data to front end, where visualisations are rerendered. Only after this is done the front end creates a timeout for the next step after 1000/FPS milliseconds. This means the fps is only accurate if taking a step and rendering it would happen instantly.
In previous versions of the front end get step was fired in exact fps time steps, but if the model wasn't running fast enough, step messages would pile up and could even render after a model reset.

If you don't know if your model is slow or the visualisation, you should try to run your model without any visualisation, maybe only printing the current step and observe if it starts to slow down after some time (and if yes look into profiling)

For the visualisation here is a little helpful quirk: if you set the FPS setting to 0 it will actually run as fast as possible, because of the calculation I mentioned above resulting in a division by zero. This might help you get faster to the point of the slow down. And if only your vis gets slow I would guess the visualization data is somehow piling up (maybe because it is sending the whole model run data or something like that).

Hope this helps. I strongly guess it is your model that slows down, but it would be interesting to know if this is because of Mesa or your specification.

[nPellejero]

Hi @Corvince ,

Thanks for your response, it is really appreciated.

Yes, I've been thinking of sharing some version of my code as an example of mesa, should I create a PR, and discuss the details to merge there?

All your hints seems to make a lot of sense, so I will give a try during this week and get back.

Thanks a lot.

[Corvince]

That would be awesome! Yes I think a PR is a good start for a discussion alongside the actual code. Don't worry if it is rough around the corners initaly!

[nPellejero]

Hi @Corvince,

I made the tests that you mentioned and I think it was clear that the module that was going too slow was the front end. Running without interfaces, the server can coup with a good amount of FPS, on the contrary, setting to 0 FPS on the front end, made that eventually the front end got frozen.

So right now, I'm looking into profiling for the front end. I think I will use some other framework different from D3 that uses the Canvas element to draw, that I have read that is more efficient. Maybe Pixi.js or p5.js (processing) or plain html5 canvas.

One thing that may interest you is that when using leaflet I had no other choice but to copy leaflet.js to /templates/js manually in the mesa package code in conda environment, otherwise I couldn't load the script properly in any other way, because when I tried using local_includes, due to having leaflet dependencies in the same local_includes list, leaflet was not properly loaded when the next dependency started to load, so then it threw an error that leaflet was needed and not found.

[Corvince]

Sorry, I wanted to get back to you earlier. Have you made any further progress?

I am curious as to way it starts fast and then slows down. Is the number of agents or anything increasing substantially during the model run? If not, can you share your code for the rendering (both in python and in JS)

One thing that may interest you is that when using leaflet I had no other choice but to copy leaflet.js to /templates/js manually in the mesa package code in conda environment, otherwise I couldn't load the script properly in any other way, because when I tried using local_includes, due to having leaflet dependencies in the same local_includes list, leaflet was not properly loaded when the next dependency started to load, so then it threw an error that leaflet was needed and not found.

Yes, the dependencies are stored in a set and the ordering is thus unpredictably. PR projectmesa/mesa#664 would solve that.

[nPellejero]

Yes, I re implemented the front end using PIXI, a js library that uses webGL and canvas renders, and now the model runs more stable at 20 FPS with around 1000 agents.

I think that the effect of slowing down after some time was just due to the i5 entering in some "boost mode" that couldn't sustain more than a few minutes.

All the iterations are much of the same, at least there aren't changes through a run that are computationally expensive. The number of agents is constant.

I would love to share the code in a PR, if you feel that can be useful. Do you think that is adequate to add my project as another folder in the examples folder of the mesa ?
Furthermore, I could share both versions, D3, and PIXI .... Which would be the best way to share both ?

[Corvince]

Yes, just create a new folder inside the examples folder. I would love to see both versions, D3 and PIXI, at least to compare the performance. This simplest solution would be to just create two server.py files, one with D3 and one with PIXI, but you could of course also have a somewhat hard-coded choice inside a single server.py, which can be changed prior to running your model.
Initially I would choose whatever is easiest for you - and then we can proceed inside the PR to see if it really makes sense to include both versions and how to handle them.

Really looking forward to your model! (and sorry for the somewhat late responses)