hi all

every once in a while i get to thinking about inefficiency. the particular inefficiency i'm concerned with right now is exe size. so many say exe size doesn't matter that i'm starting to think they read too much cosmopolitan magazine. 😉

to illustrate my point, let's look at a manufactured product. designers and engineers have refined the design to make the product cost effective to manufacture. that is rarely an easy task. even a lowly soda pop can has exactly what it needs to contain the drink, make it easy to open and easy to consume. it has a minimum of paint to help it sell and to inform people of the contents. no soda pop can has an unused functionality incorporated into it. there is no automotive spark plug just hanging off to the side. that would not only look stupid, it would be stupid. it would be cost prohibitive! the soda without the spark plug would sell better. if you want spark plugs, you go get the right one for your car, from a parts shop.

by contrast, take an exe. a simple hello world program made into an exe has zero unused stuff added to it. let's add to the hello world and include my last day of the month function.

?"hello world" + dtos(lastdayofmonth(date()))

what exactly must be in the exe to perform the function expected of it? dtos and date are native so they are included in the runtimes. my lastdayofmonth function includes a firstdayofmonth function. when i use the project manager to look at the contents of this exe, i will see a main.prg, firstdayofmonth.prg and lastdayofmonth.prg. that's exactly and precisely what must be in the exe, no more, and no less.

that's all reasonable so far. where it becomes unreasonable is when people introduce libraries. some, well, i guess most would have a library of functions. the library might be all inclusive or broken down by any number of arbitrary classifications. if i have a date function library with 10 functions (including the two above), called mydateudfs.prg, my project would show main.prg and mydateudfs.prg and that is all. clean looking in the project manager, but not clean at all in terms of manufacturing efficiency. 8 unused functions are part of the exe.

libraries are a design time convenience, maybe only good for sharing the library with someone else. it is not an efficiency at runtime. libraries make it far easier to have multiple functions with the same name! that can be a good thing in oop methodology, but is a very bad thing in procedural methodology.

at runtime the most efficient way to go is to have each function stand alone as a separate .prg file. they are included in the exe and executed directly. there is no overhead required to set procedure to mydateudfs.prg. there is no chance of two identically named functions being included in the exe.

all of us know the native function date(). at no time do we have to try and remember what library it is in. that is our natural way to program. we know we need a function and we just call it directly by name.

remember what we are producing is an exe. let's try to produce the cleanest and most effective exes. there will be added benefits. for one thing, i know a locally executing exe is faster than a shared exe. to gain that advantage i use a loader to put the latest exe on the workstation. if i keep my exe sizes efficient, the exe gets copied from the server to the workstation in the least amount of time. efficiencies pay back. inefficiencies just cost.

Leave a Reply

Your email address will not be published. Required fields are marked *