Hi all, I am trying to write a basic object-oriented matrix library, but have run into a problem.

I expected my OO routines to be somewhat slower than my equivalent non-OO routines, which was also the case (the non-OO routines uses 10 sec for a 500x500 matrix inversion, while the OO routines uses 110 secs (!) for the same).

To analyse where the problem is I have used the -pg option to make output for use in the GNU profiler, gprof. In the non-OO program I get the following:

Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name 41.27 4.42 4.42 501 0.01 0.01 _FORWARDSUBS... 30.44 7.68 3.26 501 0.01 0.01 _BACKWARDSUBS.. 28.20 10.70 3.02 2 1.51 1.51 _LUDECOMPOSITION$TAR 0.09 10.71 0.01 1 0.01 10.71 program_init

As you can see the cumulative seconds are equal to the time I measured (using "time" on the command line).

However when I run the OO program I get something like:

Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name 40.63 14.13 14.13 249874780 0.00 0.00 _SIMPLE.. [snip - a lot of lines]
0.00 34.78 0.00 1 0.00 34.75 program_init

Here the cumulative seconds only shows 34.78 seconds, even though the output from "time" gives 110 seconds...

Can anyone tell me what is going on? I guess it means that it uses a lot of time (~70%) in some internal FPC routines I have no control over?

Best regards Preben

PS: It should be mentioned that in both cases the computer had nothing else to do, and that the "time" command estimated the CPU usage to be 99%.

Which compiler did you use? Which OO model did you use?

If the answers are 1.0.6 and class then you should try the 1.1 compiler and add {$implicitexceptions off}

gprof does not know any difference between your own routines or FPC routines. If you want to know the profile results of the internal routines you have to rebuild the RTL with -pg as option. "make OPT=-pg" in the rtl/ subdir.

Peter Vreman wrote

Which compiler did you use? Which OO model did you use? If the answers are 1.0.6 and class

Right answer... :-)

then you should try the 1.1 compiler and add {$implicitexceptions off}

OK, I'll try the 1.1. What does the {$implicitexceptions off} do (I guess it turns implicit exceptions off, but... :-))? I couldn't find anything about it...

gprof does not know any difference between your own routines or FPC routines. If you want to know the profile results of the internal routines you have to rebuild the RTL with -pg as option. "make OPT=-pg" in the rtl/ subdir.

Hmm, I might do that... :-) But first I'll try the two other suggestions...

Best regards Preben

It's very new, so it's not documented yet. It was created to speed up the compiler, the result was about 15%.

What it does it removes the expection frames from constructors. The result is that implicit initialized local variables are not freed when there is an unhandled expection in the constructor.

OK, I have just tried it. The result is:

104 secs for fpc 1.1 with implicitexceptions off
108 secs for fpc 1.0.6

So this didn't help much. However I'm quite sure that it has to with the OO-methods for accessing array-elements (this will of course be slower than accessing the elements directly :-)). So I will just (maybe) have to not use these methods in descendant classes if I want better performance...

Best regards Preben

If you mean properties implemented with methods compared to accessing a real array, this is very probably the case ;-)

However I'm quite sure that it has to with the OO-methods for accessing array-elements

Having no idea what this object is doing, I might be way out of line here, but maybe it would speed things up to implement some sort of a "ForEach" callback, rather than indexing the array on each call.

So instead of:
  for i:=0 to Obj.Count-1 do Proc(Obj.Prop[i]);
You might have something like this:
  Obj.ForEach(@Proc);

__________________________________________________ Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com