Future Live Mode Semantics
Posted: Sun Mar 11, 2012 7:04 pm
I've been thinking about live mode (in the last 15 seconds or so) and realised that if we allow it to eat and eat memory, then it'll interrupt the flow of the data across the screen each time it increases the array size. IE, that's unacceptable. What this means is that we have to let the user set a buffer size to use (N samples long) and treat it as a circular buffer. Ben, when you get a chance to think about that, do, and let me know what is likely to come apart at the seams if/when we enabled that mode of operation.
The other thing that that means is that after N samples we'll be throwing away data, so we'll also need to write data out to a file as we go using a buffered writer that writes fairly regularly to keep things smooth, but not too regularly or it'll eat too much CPU.
This message brought to you by a console window that said 2600 records loaded in 37000ms or, 15ms per record, or 65Hz max sample rate before host CPU saturation (with my current other loads). This is fairly worst case, the machine is being a dog at the moment, however is slower than FreeEMS pumps them out, so needs to be improved, I guess. There is an API that needs adding in your drawing classes such that we can improve the efficiency of the data classes. The change will be one that enables you to extract the data natively and display it without significant processing. At the same time I'll then be able to populate it natively and save a shit load of CPU time in the process, not to mention a factor of 8 memory in many cases which will also save time doing array resizes during load, should they be necessary. It's not a priority at all, and I'd like to be heavily involved in that change, but keep it in mind.
Fred.
The other thing that that means is that after N samples we'll be throwing away data, so we'll also need to write data out to a file as we go using a buffered writer that writes fairly regularly to keep things smooth, but not too regularly or it'll eat too much CPU.
This message brought to you by a console window that said 2600 records loaded in 37000ms or, 15ms per record, or 65Hz max sample rate before host CPU saturation (with my current other loads). This is fairly worst case, the machine is being a dog at the moment, however is slower than FreeEMS pumps them out, so needs to be improved, I guess. There is an API that needs adding in your drawing classes such that we can improve the efficiency of the data classes. The change will be one that enables you to extract the data natively and display it without significant processing. At the same time I'll then be able to populate it natively and save a shit load of CPU time in the process, not to mention a factor of 8 memory in many cases which will also save time doing array resizes during load, should they be necessary. It's not a priority at all, and I'd like to be heavily involved in that change, but keep it in mind.
Fred.