Slow performance on linux - workaround

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Slow performance on linux - workaround

Evan Thomas-2
Some time ago I reported a problem with slow octave performance running
on linux. Further investigation prompted by people on the list showed
that the problem occurred only with the "lsode" function and then not
with all ODEs (for instance linux performed benchmark ODEs as one would
expect).

It appears that the problem is related to checking that function files
haven't been updated on disk. By setting
ignore_function_time_stamp="all" the PC performance is what one would
expect. (This is why my equations were slow and the benchmark ones were
OK. In my case the DEs called some user defined functions.)

The problem is related to the kpathsea functions that look for the file
in the search path. By removing the call to fcn_file_in_path() in the
function symbol_out_of_date() the performance problem also goes away. I
don't why this would be a problem on linux and not on the Sun.

I have not attempted to reproduce the problem in circumstances other
than solving ODEs.

Thanks, Evan.
--
Evan Thomas
Department of Anatomy & Cell Biology
University of Melbourne
Parkville, 3052
ph: 9344-5849  fax: 9347-5219

Reply | Threaded
Open this post in threaded view
|

Re: Slow performance on linux - workaround

Jim Van Zandt
In message <[hidden email]>, Evan Thomas write
s:
>Some time ago I reported a problem with slow octave performance running
>on linux....
>
>The problem is related to the kpathsea functions that look for the file
>in the search path. By removing the call to fcn_file_in_path() in the
>function symbol_out_of_date() the performance problem also goes away. I
>don't why this would be a problem on linux and not on the Sun.

Maybe the Sun had enough memory that the relevant disk sectors
(directory entries for the function files) were all in buffers, so no
actual disk access was needed.  

You could try freeing up memory by getting rid of X windows and other
terminal sessions, and ensuring there's plenty of swap space (so
little-used code can be swapped out), and simplifying the search path.

Alternatively, you could try filling up the memory on the Sun to see
whether the performance problem appears there.  You could write a
trivial program that mallocs a block of memory then waits for a
specified time or a keypress.  I suppose you would have to fill up
swap space before it would have any impact.

                                    - Jim Van Zandt

Reply | Threaded
Open this post in threaded view
|

Re: Slow performance on linux - workaround

Evan Thomas-2
Jim Van Zandt wrote:

>  
> Maybe the Sun had enough memory that the relevant disk sectors
> (directory entries for the function files) were all in buffers, so no
> actual disk access was needed.
>
> You could try freeing up memory by getting rid of X windows and other
> terminal sessions, and ensuring there's plenty of swap space (so
> little-used code can be swapped out), and simplifying the search path.
>
> Alternatively, you could try filling up the memory on the Sun to see
> whether the performance problem appears there.  You could write a
> trivial program that mallocs a block of memory then waits for a
> specified time or a keypress.  I suppose you would have to fill up
> swap space before it would have any impact.
>
>                                     - Jim Van Zandt

This almost certainly isn't the problem. The Sun is running X, acting as Web
server, doing file and e-mail serving, etc. The Linux box is just running octave
over an rlogin session - nothing else (normal it runs that other operating
system, I just get to use it occassionally). Both machines have 32Mb of memory
and neither appear to be doing significat IO (ie paging) when octave is running.

I tried setting the LOADPATH to the current directory only (LOADPATH=".") but it
didn't fix it. (My functions are in the current directory, anyway, which is the
first in the search path.)

Evan.
--
Evan Thomas
Department of Anatomy & Cell Biology
University of Melbourne
Parkville, 3052
ph: 9344-5849  fax: 9347-5219