On Mon, May 25, 2009 at 4:52 PM, sergio masci wrote: > Turns out the library was at fault. > It took weeks to track down the fault, much longer than if we'd written > our own. How do you tell a client "actually the fault is with a SW > component we bought in" - it doesn't wash > I agree that it could happen. However, if you buy a library from a sw company that has hundreds or even thousands of clients using the same library then the chance that the code is more reliable than your in-house one is quite high -- simply because more people are testing it in a more variety of systems. You might can make it more compact though as the in-house one was designed for your needs only not for average requirements. On Mon, May 25, 2009 at 4:52 PM, sergio masci wrote: > He was tracing though the executable and was > appauled to find that it took hundreds of millions of malloc calls just to > print "hello world". Yeh sure you can get JIT (just in time compiling) for > your Java program but how does that help when the libraries need to go > through heavy duty memory management to achive trivial things. > Most HLL is quite inefficient on small code as they have a relatively big startup code initializing a larger set of libraries and as they generalize the system for average needs instead of specifically yours. The real question is always whenever the HLL is still resource waster when you have a huge code base and also if you can achieve a better code in shorter time. Usually it is a complex calculation how can you get more profit -- if you take a high speed mcu/cpu with plenty of resources and hll development buying libraries etc so you have a product in a small turnover or do the opposite so you save money on the production but spending much more time during the development phase. My guess is that the answer is usually somewhere in between. Tamas -- http://www.mcuhobby.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist