octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #57439] handles to private functions may fail


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #57439] handles to private functions may fail after "clear functions"
Date: Sun, 1 Mar 2020 14:18:14 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #42, bug #57439 (project octave):

Same tests on Mageia 7 64b on the same box:

>> t = cputime
>> __run__test_suite__
:
:
>> cputime - tt
ans = 143.40


and the io package loads in .6 seconds (loading all Java classes for all Java
based spreadsheet interfaces, just like on Windows).

(Remarkable; until I think some years ago  __run_test_suite__  used to be
quite a bit faster on Windows than "make check" on Linux. Now that I ran 
__run_test_suite__  for the first time on Linux I see that Octave is much
faster there, at least for file I/O)
(BTW I didn't know that to be able to run  __run_test_suite__ , octave needs
to be installed)

In the related maintainers ML thread where I first reported the performance
degradation [1] I also mentioned that run.m would somehow show that it
manipulates the load path.
Just a far-fetched throw in the dark (sorry, I don't know all about several
Octave internals): does the fix for this bug report lead to extra manipulation
of load paths? because (I suppose) fiddling load path stuff could also invoke
PKG_ADD things and that could take a lot of time.

[1]
https://octave.1599824.n4.nabble.com/Octave-on-Windows-takes-a-long-time-to-start-amp-run-m-reloads-Of-packages-tt4695555.html


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57439>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]