Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
6 years, 10 months ago.
Mbed LPC1768 Too Slow for Virtual Methods
I've written an OOP program which calculates the position of an object following a Trapezoidal motion trajectory - accelerate up to max speed, coast until decel point, decelerate to target position.
The trajectory code is based around a state machine using virtual methods.
When I run the code on my Macbook, the program completes in a few seconds. On the mbed LPC1768 dev board, the program takes minutes to complete (far too long for my needs).
Is there anything in my code which could be slowing down the program? Should I upgrade to a more powerful chip? I'd really like to keep the OOP state machine if possible.
Perhaps somebody could run the program on other mbed board and see whether it completes in less time.
/media/uploads/ebutt13/trapezoid_lpcxpresso_lpc1768.zip
2 Answers
6 years, 10 months ago.
Hellow Edward,
Try to to remove or comment the line
pc.printf("%f\n", pos);
After such modification it took about 105 ms (105 533 us) to complete the execution on an LPC1768 board and only 38562 us on an STM32F767ZI board.
NOTE: To display the time elapsed in ms or us you may call t.read_ms() or t.read_us() respectively.
Thanks Zoltan, I'll try that out.
In your opinion, is the structure of my program (i.e. the state machine) overly complicated for the task at hand? Would it be worth re-writing it into a simple class?
posted by 21 Jun 2017As Erik says, it depends on your priorities and main goal. When you make a virtual function call through a base-class pointer, the compiler quietly inserts code to fetch the virtual pointer and look up the function address in the VTABLE. This requires both code space and execution time. If you would like to achieve maximum speed and minimum size then you must sacrifice the elegance of OOP and optimize your code. However, unofficial evidence suggests that the size and speed impacts of going to C++ are within 10 percent of the size and speed of C, and often much closer to it. So if you are able to meet your requirements on speed and size using OOP then keep your code as it is. I personally prefer OOP over procedural programming (so I’m biased) which is one of the main reasons I like mbed.
posted by 22 Jun 2017
6 years, 10 months ago.
How often is Handle called before it is done? The virtual functions won't help with speed, especially since I have a feeling these are called a ton of times. And while sometimes dynamic allocation (new operator) is useful, in general on embedded systems it is preferred to avoid them. And for something like this it seems not really required.
So to me a state machine seems excessive. But it also really depends on what you are trying to do with this exactly. If you only need the position at three points, I would advice you to do the math and just get the formulas where you give the time, and it returns the position directly. But if you need to get the position all the time, then a numerical calculation like what you are doing here might be best.
I assume on your macbook the issue is similar, where it spends more time printing than running calculations. But in general if something takes on a real PC several seconds when it is a relative simple calculation you do, then your solution is probably not ideal.
When you say dynamic allocation seems unecessary, are you suggesting I use smart pointers instead, or keep everything in the stack of the context object (would that work...?)?
You say a state machine seems excessive which I'm starting to agree with. Would a simple case/switch statement representing each state, contained within a class be more suitable?
On a side note, do you think my code follows good C++ practises, is safe, etc. I'm new to the language and am writing/structuring code in the same way id write java.
posted by 22 Jun 2017