I am working on a module using the Breadboard X1 on a FEZ Spider running 4.3. Among other things, the module makes use of the four built-in LEDs, attached to four GPIO pins, and I am writing a Gadgeteer module driver that provides application control of the LEDs (among other things).
Because I anticipate a lot of toggling by the application of LED states, which requires knowing the current state of the toggled LED, I was wondering which of the following would be better performing:
GTI.DigitalOutput Read() to get the current state.
OR
Keeping a private bool that contains the current state, and reading it when needed.
The latter assumes that all changes to the LED states are done through the module’s driver interface, so the bool should always be in sync with the actual LED state.
I guess what I’m getting at is this: Is reading a GPIO pin via Read() more expensive than reading a variable out of memory? Or are they roughly the same?
@ kgcode - My advice on a question like this would be to test it and see. Write a loop that toggles the led 100 times and time how long it takes using the DateTime and TimeSpan classes (alternatively you can use one of the numerous Stopwatch classes on Codeshare). Try both methods and report your results.
My guess is that the variable will be significantly faster than the read, the question is does it matter and is it worth the added effort to keep the state in sync etc. if for example on runs at 500 times per second and the other at 1000 times per second it might not matter since the eye will not see the difference, depending of course what you want to achieve. But it is still worth knowing the difference because tomorrow you might want to toggle something other than a LED and you might need the added performance. So I would say defiantly test and share, at the very least I would be interested in the results.
I agree that measuring is the way to find out definitively, and I will do so and will share my results. I was just wondering if someone already knew that one was more expensive than the other. My guess is that, because the Read() is going to be an actual method call in NETMF, and accessing the a private bool member variable doesn’t involve a method call, the bool should be cheaper. But it’s a guess.
While I do realize that some applications using the module might not care about how optimal this is, I want to make this driver as performant as I can, so that I can minimize getting in the way of other activities the application might need to do. I’m just completing the Read() approach, but because the implementation of the bool approach is trivial, if there is any performance advantage to the bool, I will likely go in that direction.
Anyway, I will measure and share once I get the driver up and running.
Here are the performance measurements, which seem to support our guess that Read() is more expensive than using a bool to keep track of the LED state. The test was performed with the same driver, using two different method calls to toggle the LED. 6000 iterations of each toggle approach were timed.
Using Read() to get the current LED state: 3.794 seconds
Using a bool to keep track of the current LED state: 2.740 seconds
In the bool case, the bool was read and updated, and the updated result was used to Write() the new state of the LED, but no call to Read() was performed.
The test was run several times to confirm that the results are consistent across runs.
@ kgcode - That is great, thanks for sharing! Now the interesting thing is you are using a spider with external memory, doing the same test on a Cerb for example might show an even bigger difference since the Memory is not external like on the spider.
Thanks again for sharing, when I eventually get my boards updated I am going to give this a try…
The other issue to consider is the precious memory taken up by the private bool. Granted, 4 will probably not make a difference, but if it was an array of 4 x 4 led’s, it just might.
Agreed. It’s a tradeoff between size and speed. There are four LEDs on the module, and my reported measurements were taken using an array of four bools (i.e., four bytes of storage). I also tried implementing it using a single byte, manipulating bits within that byte as the LED states were changed. The timing difference between using four bools vs four bits within a single byte were negligible, but the bit manipulation approach would save three bytes of storage. (Unfortunately, I neglected to measure the code size difference between the two approaches, so it might be a wash.)
Of course, relying on bools or bits to stay in sync with the actual LED states won’t play very well if the application is accessing the module’s methods and properties through multiple threads. Short of adding locking, reading the actual pin trumps maintaining the state in member variables.