embedded software boot camp

(Code) Size isn’t everything…

Thursday, May 7th, 2009 by

I have been looking at some code sizes recently and wondering why GUI code gets so darn big. I can understand that compiling in fonts and bitmaps are bulky and so the executable size can get big, but even when measuring lines of code the number of lines taken up by the GUI always seems to be greater than the rest of the system put together.

I pointed this out on one project where we had about 12 KLOC (thousand lines of code) for the GUI and about the same for the rest of the system. One of the other engineers quite reasonably queried if I had included the third party library that we were using. No – that was another 30 KLOC that I had left out; since it was not ‘our’ code (i.e. we did not write or maintain it). That 30 KLOC dwarfs our system, though I guess we probably only used about 20%. Still, a fair chunk of the graphics code was done for us before we even started.

So even when a lot of the drawing and filling routines and screen drivers are left out you still find your self with tons of code to manage what is visible on the screen. And I have seen this pattern repeat on many projects.

“So what” you might say. The interesting thing for the developers is that if the company is making photocopiers, then some of their programmers are going to have knowledge specific to photocopying, ink pump control and the like. But once their photocopiers get more complex and have a GUI on board the company is going to spend just as much on GUI expertise. If they do not purchase some third party tools, then you are going to spend an awful lot (of time/money/resourses) on graphics code.

All this is worth knowing when you are hiring a new engineer, or if deciding to buy a GUI library, or write one yourself. Having a sense of the size of the challenge helps drive good project management decisions.

In fairness the 50/50 split might be slightly exaggerated. Controls code is often shorter but more difficult to write than GUI code, so each 1000 lines of code is not an equal measure.

The numbers still tell me that there is a real benefit in third party tools that dramatically reduce the workload on the GUI portion of the project – since that is a big chunk of the total project, and there are even cases where you can justify spending more on the hardware if it makes the programming job easier.

If you have used any tools that you think tipped the balance on the amount of GUI code that you had to write, let me know.

2 Responses to “(Code) Size isn’t everything…”

  1. Nigel Jones says:

    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).

  2. Niall Murphy says:

    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.

Leave a Reply