> N_LOOPS: 1000000 df ko
> [ T000: empty loop overhead ]............................0.03 .0.03
> ============================================================= =====
> [ T001: x := L_C ].......................................0.05 .0.05
> ...
> [ T030: x := &( "f1(" + str(i) + ")" ) ].................3.78 .6.14
> [ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ].........4.25 .4.31
> ...
> ============================================================= =====
> [ total application time: ].............................29.86 32.13
> [ total real time: ]....................................29.92 32.19
IMO, the speedtst is just a waste of time in real world, sorry.
For example, the overall diff between df and ko of about 2 seconds for
1000000 loop, means 0.000002 sec per loop should be unnoticable in real
application.
I believe there must be some more proper basis for benchmarking (of an
application). Sometimes, they vary from one to another. Cross-compiling
frequently takes great roles in optimizing an application.
One of my app uses Blade MP3 Encoder which can be found on:
http://home.swipnet.se/~w-82625/default.htm.
The encoding process is noticable slow when I compiled the encoder with
MSVC 2008, eventhough speedtst compiled with MSVC 2008 is the fastest one.
Same slowness was also demonstrated by ICC, not to mention BCC or OW.
Unexpectedly, I compiled the encoder with GCC in DLL-format...and
kabooom !! ... I found that the module works 8 to 10 times faster than
if I compiled it with non-GCC.
My conclusion is, an experiment in using more than one C compiler in
building an application, is worth enough to achive a real speed.
--
Andi
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
