On Thu, Mar 22, 2007 at 03:55:10PM -0700, troy engel wrote: > (unplug and plug in device) > $ time ./bcharge-c > Scanning for Blackberry devices... > Found device #002...adjusting charge setting...not a Pearl...done > real 0m0.003s > user 0m0.001s > sys 0m0.002s > > (unplug and plug in device) > $ time ./bcharge-cpp > Scanning for Blackberry devices... > Found device #003...adjusting charge setting...not a Pearl...done > real 0m0.005s > user 0m0.002s > sys 0m0.002s > > We gain a bit of time back -- I mean we're talking a super low amount > of time here, just the blink of an eye. But still, would there be a > compelling reason to kep bcharge as a CPP compiled binary instead of > switching to C?
No offence guys, but I think this is a bike shed issue. :-) http://en.wikipedia.org/wiki/Color_of_the_bikeshed With the results above, we're talking about 1 one thousandth of a second of user time, for a program that runs once, and does not stay in memory, so size isn't really an issue. On my system, a stripped bcharge.cc comes in at a whopping 5492 bytes. And to compile the rest of Barry, you'll need a C++ compiler anyway, so it's not assuming more than is needed by everything else. If you're really concerned about C compatibility, I'd encourage anyone interested to look at the cbarry.h header, where you'll find a work-in-progress set of prototypes for using Barry from straight C applications. It needs to be implemented, and the API hasn't been fully designed yet. Feedback on that would be great. - Chris ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
