http://embeddedgurus.com/usability-bites/2009/05/code-size-isnt-everything/ A Blog by Niall Murphy Fri, 21 Jan 2011 16:47:04 +0000 hourly 1 http://wordpress.org/?v=3.3.1 http://embeddedgurus.com/usability-bites/2009/05/code-size-isnt-everything/comment-page-1/#comment-7 Niall Murphy Wed, 13 May 2009 05:10:00 +0000 http://embeddedgurus.com/usability-bites/2009/05/07/code-size-isnt-everything/#comment-7 I agree with Nigel that it would be handy to have a guide to which are the more expensive (in terms of code size, and maybe speed) objects and which are less resource hungry.I think any such guide would be fairly rough because the cost of many objects varies with use. A BitmapButton's size probably depends more on the size of the bitmap than it does on the code of BitmapButton itself. Similarly fonts (especially Kanji) can take up big chunks of ROM, and that is beyond the control of the GUI library.If vendors are going to start categorizing their objects, I often wish that would also document which ones use dynamic memory and which do not. Some projects try to apply a coding standard rule that no dynamic memory management is allowed after startup, and this is sometimes possible with a GUI toolkit, as long as you avoid certain objects. I agree with Nigel that it would be handy to have a guide to which are the more expensive (in terms of code size, and maybe speed) objects and which are less resource hungry.I think any such guide would be fairly rough because the cost of many objects varies with use. A BitmapButton’s size probably depends more on the size of the bitmap than it does on the code of BitmapButton itself. Similarly fonts (especially Kanji) can take up big chunks of ROM, and that is beyond the control of the GUI library.If vendors are going to start categorizing their objects, I often wish that would also document which ones use dynamic memory and which do not. Some projects try to apply a coding standard rule that no dynamic memory management is allowed after startup, and this is sometimes possible with a GUI toolkit, as long as you avoid certain objects.

]]> http://embeddedgurus.com/usability-bites/2009/05/code-size-isnt-everything/comment-page-1/#comment-6 Nigel Jones Wed, 13 May 2009 00:21:00 +0000 http://embeddedgurus.com/usability-bites/2009/05/07/code-size-isnt-everything/#comment-6 I'm a big proponent of using a third party graphics package - in part because I think companies should concentrate on their core technologies. Having said that, one of the things I'd like to see documented a lot more in graphics libraries is both the absolute and marginal costs of each type of control. In other words, what will it cost me to use widget X if I'm already using widgets C, H & P? I can of course run experiments - but I'd rather have this information up front so that I can plan my UI. As well as helping minimize the size of the object code, this also allows me minimize the potential number of bugs (using the simplistic assumption that bugs are uniformly distributed throughout the code). I'm a big proponent of using a third party graphics package – in part because I think companies should concentrate on their core technologies. Having said that, one of the things I'd like to see documented a lot more in graphics libraries is both the absolute and marginal costs of each type of control. In other words, what will it cost me to use widget X if I'm already using widgets C, H & P? I can of course run experiments – but I'd rather have this information up front so that I can plan my UI. As well as helping minimize the size of the object code, this also allows me minimize the potential number of bugs (using the simplistic assumption that bugs are uniformly distributed throughout the code).

]]>