On 24 May 2010, at 20:12, Thomas Weber wrote: > On Mon, May 24, 2010 at 06:06:10PM +0200, c. wrote: >> >> On 24 May 2010, at 10:39, Thomas Weber wrote: >> >>> Ignoring the bug report, >> I do not want the bug report to remain ignored, I am willing to help >> find a fix, just not this way. > > I meant this in the sense of "even without the bug report". I guess > it's > fair to say that this is not a real bug in the ocs package. > >>> the issue of start-up time for Octave remains. >> I don't think there is any measurable performance hit due to the more >> directories added to the path, can you show any numbers supporting >> this? > > With quite some octave-forge packages installed (actually, all that > are > in Debian currently; v.m contains just an exit; command); > > $ time octave v.m > <snip> > > real 0m2.820s > user 0m2.168s > sys 0m0.112s > > without any packages: > real 0m0.423s > user 0m0.236s > sys 0m0.048s > > So, the difference is measurable. However, most people will probably > have longer sessions, where start-up time isn't a big issue.
I tried the same test on my system and the number I see are consistent with yours. The only case where a startup time < 3s may matter though is when Octave is being invoked many times within a script. In that case I would say it's better to invoke Octave with the "-qf" option and explicitely load only those packages that are actually needed, e.g. you might want to try this: time octave -qf --eval "pkg load ocs" v.m then try putting all files from ocs into one dir and rerun the test. anyway you should consider that ocs is marked as "Autoload: no" so its presence should not usually influence startup times. > Measuring > the influence of a bigger loadpath isn't as straightforward as startup > time, though. I think directories that are not included in the check for changed time-stamps should not influence octave's performance, right? is the path where debian puts the packages within what "ignore_function_time_stamp" considers system directories? > Reconsidering this is obviously a choice. However, as it seems that > currently only ocs is hit by this, I'm looking for something else. what about secs1d and secs2d? they also have subdirectories do they suffer the same problem? >>> [1] http://www.pathname.com/fhs/ >> I'll have a look at the link and see if it helps me find out a way >> around this problem > > Hold your horses. This is a distribution-specific problem. Moving > all .m > files into one directory would be an easy solution, but your > explanation > for the split-up is fair. > > Thomas ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
