[Lazarus] Embedded database for Lazarus/Linux

Santiago A. svaa at ciberpiula.net
Sat Jun 26 16:44:53 CEST 2010


El 18/06/2010 20:18, waldo kitty escribió:
> On 6/18/2010 12:39, Jürgen Hestermann wrote:
>> but I would prefer if programmers think
>> about performance a bit and not use databases for every
>> small junk.
>
> +100000000000(can't put enough zeros)00000000000000
>
> imagine how fast our apps would be today if they were developed with
> the same attention to compactness and speed as they were 10 years
> ago... they'd be even faster if the attention of 20 years ago was used...
>

It is a problem of coding time vs other resources. It is a problem of
reuse vs specialized routines.

If you don't write things from scratch, you begin to use libraries and
the program gets bloated. Even when you write parts form scratch,
sometimes you say "I will extend this procedure so it could be used also
for...". When you extend a procedure you add IFs to control different
cases, so you are penalizing performance a little. Whenever you, as
programmer, make the decision "I don't want to worry about these details
when I'm coding, I will let the software takes care of those nasty
details", you are relieving of work, and charging that work on the
software. Instead of making decisions in code time, you let the software
make decisions dynamically in runtime. That has  some impact on
performance, perhaps only a little, perhaps negligible, but accumulative. 
 
A simple case: How many times we use a TStrings when an array of strings
would be enough?. How many times in FCL and LCL is TStrings used?.
TStrings is a good convenience that is why we used it instead of
declaring an array of string of fixed size even when we know the size in
advance.

In the old days, adding an IF in each iteration was expensive in
performance. Now 1000 IFs per iteration have no impact. Unfortunately,
every body does it,  so everybody uses 1000 IFs per iteration and
finally we have 100.000 IFs that have some impact.

It is difficult to balance between coding time and performance. But
comparing with code written 20 year ago is unfair. It was more simple,
now we demand a lot to a simple program. And in the old days many things
were written almost from scratch. Nevertheless, perhaps we have gone too
far and we should be a little more careful.

Santiago A.








More information about the Lazarus mailing list