ArmA2 FPS analyser - benchmarking tool

[Old_Painless]

Aha, brilliant. Found it

Will try it out now with a clean rpt file. As for usage, you say that we should keep Arma2 running, Tab out of it and run the tool. Will the tool not work if we close down Arma2 and then run the tool?

[sbsmac]

Yes - it will work if you shut down ArmA2 first. In fact that's a better way to do it :-)

[Old_Painless]

OK, Cheers.

[Suma]

I understand the affect of 'acctime' of course, and also notice that if the game is actually halted (eg, if it is dragged whilst windowed) 'time' is halted. Other than that is it an inherently unreliable measure ?

Yes, it is inherently unreliable. There are other edge causes besides of time acceleration. One case which is of particular importance here (and which was the reason why we added the new functions while developing internal automatic fps testing) is time is unreliable once game fps is low. The problem is once simulation is using all available CPU power and running on the largest possible time delta, there is no way game time could keep up with the real world time and game time must be slowed down. In practice this means that once the game is running under ~10 fps, the game time will be running slower, therefore if you use it for bechmarking, the fps will be seemingly higher than it really is.

[sbsmac]

Thanks Suma, I really appreciate the information. Benchmarks have now been modified to used diag_ticktime so should be more accurate.

[Sickboy]

What I would be interested in would be measuring the current load of scripting engine, to measure the performance of the running scripts.
I'd want to use it to make simple comparisons between vanilla, cba, cba+ace, aswell as compare different versions / different systems on / off, in different situations, to measure the effect these scripts have on the performance and especially delays.

Since the spawned scripting is now scheduled, FPS is no measurement for it, maybe it is something your tool could support, or if anyone has some ideas on how to accomplish this?

[sbsmac]

That's an interesting idea Sickboy. Unfortunately it's usually very difficult to measure overall scheduler load from within a scheduled thread ! What you really need to do is read the start and end time of each scheduler slice but it's impractical to do this from within the scripting environment - there isn't any way to force the execution of code at the beginning and end of a slice. What might work would be if a new diag function was added...

diag_TimesliceInfo - the return value would be an array containing the start and end timestamps of the previous timeslice, eg [5.678,5.683]. Alternatively, the return value could just be the duration but I prefer to see start and end.

If that was available, it would be very easy to plot script usage in a number of ways.

As a poor substitute, it is already possible to measure individual script performance by adding diagnostics at the start and end of the script and I could easily modify the tool to allow this to be output and plotted. The drawback is that any system of scripts complex enough to be interesting is also complex enough that instrumenting it completely is impractical.

Let me have a think on it...

*Edit* What would simplify the above problem is something like diag_scriptTimes where the return value is an array of script handles and duration used during the previous timeslice.

Even this isn't perfect - there is a chance that the monitor script will not get the opportunity to run during any given timeslice but this condition could be detected by including a timeslice-id in the results array. I'll put some more thought into this and raise a CIT ticket.

[sbsmac]

Here's a mock-up of what it could look like (with randomly-generated data in this case).

[Alex72]

Thank you sbsmac for the fix. All good now.

Could you expand the highest FPS value in the charts? 100FPS is max and it seems i have dots in those highest values wich could/should mean i had higher FPS than that. Could be nice to see maximum. Maybe 200FPS could be maximum? Thinking of own benchies people will make where you do flying higher up. That gives me sometimes ~200FPS.

EDIT: When i did another run with different settings i noticed that the first run has the same time stamp as the last one so its hard to know wich is wich. I know from the numbers #1 and #2 of course but with a bunch it will get harder. So every bench has the same time stamp wich is from the last run. Could be nice if that is fixed. I also noticed that the second run where i upped the settings a bit took the highest FPS value in the windows down to 80 - even when i select the first run only wich was above 80FPS in the peaks.

Will be on MSN later if you want better explanations. Thanks again for creating this. Much appreciated tool.

[sbsmac]

Alex, you can use the View->Zoom->Custom to set the maximum fps on the graphs. It never occurred to me that people were likely to get over 100fps ! ;-)

The timestamps are generated from the 'session', ie the time at which you started ArmA2. Unfortunately there is no way from within a mission to directly get the system time, hence the #1,#2 etc (Actually, thinking about it I might be able to do something to calculate the time of the benchnmark using diag_ticktime as an offset from the session time.) Anyway... if you go to the benchmarks->details page, you will see a text-edit box called 'label' and you can use this to assign more meaningful labels to particular benchmark runs.

>I also noticed that the second run where i upped the settings a bit took the highest FPS value in the windows down to 80 - even when i select the first run only wich was above 80FPS in the peaks.

That seems a bit strange - I will take a look to see if there is a bug there.