From maintainers-request at octave dot org Thu Mar  3 20:45:59 2005
Subject: Re: Report on progress...
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Daniel J Sebald <daniel dot sebald at ieee dot org>
Cc: maintainers at octave dot org
Date: Thu, 3 Mar 2005 21:52:03 -0500

On  3-Mar-2005, Daniel J Sebald <daniel dot sebald at ieee dot org> wrote:

| Daniel J Sebald wrote:
| > dsebald at acer-access dot com wrote:
|  >
| > I note an improved performance in speed for some intensive number 
| > crunching.
| > A program to process multichannel data has gone from:
| > 
| > with 2.1.64
| >   textstr = 0, 3.233
| >   textstr = 1, 88.33
| >   textstr = 2, 171.8
| > 
| > with 2.1.65
| >   textstr = 0, 3.226
| >   textstr = 1, 64.41
| >   textstr = 2, 123.9
| 
| Hmm, I recompiled Octave with the --enable-shared option to include OctaveForge and I'm back to the 
| original numbers:
| 
| with 2.1.65 and --enable-shared
|    textstr = 0, 3.676
|    textstr = 1, 86.18
|    textstr = 2, 166.4
| 
| Does Octave slow down with shared libraries?  Probably so, but 30%?

It might be slightly slower to have functions like min or max in .oct
files instead of built-in, because they have to be loaded.  If you are
running with a slow filesystem (NFS, AFS) it could be significant.
But I would not expect a huge slowdown.  The filesystem is only
supposed to be checked once per prompt, not at every function call.

The number one rule of reporting problems is that you have to provide
enough information for someone else to reproduce the problem or there
is little hope that anyone will be able to guess what is causing the
trouble.

<broken-record-mode>
If you think you have found a bug in Octave, please send a complete
report to the bug at octave dot org list.  If you are not sure what to
include in your report so that someone might be able to fix the bug,
the please read http://www.octave.org/bugs.html before sending your
report.
</broken-record-mode>

Thanks,

jwe