Added queue.getFps() function and tests for this function

[Erol444]

Works (as expected). I consulted o3-mini-high and they approved it already.

% ./message_queue_test
Randomness seeded to: 2163801883
===============================================================================
All tests passed (63 assertions in 18 test cases)

[moratom]

The test didn't fail before, I think this introduces a race condition in the code.

[moratom]

Thanks!

Left a few comments about thread safety, but other than that looks good to me.

Might be worth considering a LockingQueue (the same as is used for the messages) since it's already thread safe and "battle tested".

[moratom]

What's the reason behind the treshold? I would set a max queue size instead so it's more consistent for low and high FPS

[Erol444]

@moratom well if you have script node and queue suddenly stops receiving messages, it would still report last FPS. Instead this logic removes messages older than 2sec so you get real FPS.

[SzabolcsGergely]

How about getMessagesPerSecond instead getFPS?

[Erol444]

@SzabolcsGergely while it's more accurate, I think most people are used to FPS, even if it's actually Inference per second / Messages per second. Pehraps we could go with getQueueHz(), which is also quite widely used (aka hz == fps)?

[SzabolcsGergely]

@SzabolcsGergely while it's more accurate, I think most people are used to FPS, even if it's actually Inference per second / Messages per second. Pehraps we could go with getQueueHz(), which is also quite widely used (aka hz == fps)?

I don't see getQueueHz fit/good choice, personally.
This measurement refers to queue message rate per second.