Octave on Windows takes a long time to start & run.m reloads Of packages

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

Octave on Windows takes a long time to start & run.m reloads Of packages

PhilipNienhuis
While running __run_test_suite__ with a freshly cross-built Octave-6.0.0 on
Windows, I saw a FAIL in run.m.
That FAIL has been there for quite some time, didn't bother, "test run.m"
works fine when run outside of __run_test_suite__.

But because since one or two days Octave on Windows suddenly takes a very
long time to load I added some tic/toc statements in
chk_spreadsheet_support.m, invoked by __init_io__.m, in turn invoked by
PKG_ADD in the io package, to find out if loading Java classes for
LibreOffice would take so long. I saw no strange things there, finding &
loading loading the .jars takes altogether ~5-6 seconds of in total 25
seconds for he gUI to appear until the prompt is shown.

And now I see this when running __run_test_suite__.m:

:
  miscellaneous\recycle.m ........................................ pass  
5/5
  miscellaneous\run.m ............................................Loading
regular .jars ... Elapsed time is 0.000999928 seconds.
Loading UNO .jars ... Elapsed time is 0 seconds.
Loading regular .jars ... Elapsed time is 0 seconds.
Loading UNO .jars ... Elapsed time is 0 seconds.
 pass    4/5
                                                                   FAIL    1
  miscellaneous\setfield.m ....................................... pass  
6/6
:

and running "test run.m" by itself:

>> test run.m
Loading regular .jars ... Elapsed time is 0.00100088 seconds.
Loading UNO .jars ... Elapsed time is 0 seconds.
Loading regular .jars ... Elapsed time is 0 seconds.
Loading UNO .jars ... Elapsed time is 0.00100112 seconds.
***** test
 path_orig = path ();
 tmp_dir = tempname ();
 test_function = fullfile (tmp_dir, "tf.m");
 unwind_protect
   mkdir (tmp_dir);
:
< and the rest of the run.m test>

and there's a long delay before I see output from "test run.m". Once the
messages from chk_spreadsheet_support.m are shown, the rest of the output
comes fast.

So it looks like Octave now does a lot of things when running run.m, a.o.,
it seems to re-load the OF packages (because AFAICS that's the only way
chk_spreadsheet_support canbe invoked twice). Or maybe it rebuilds the
complete path, who knows.

Q.: Can anybody confirm this?

Q.: If confirmed, what is the cause, and does Octave work as it should?

Thanks

Philip




--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Octave on Windows takes a long time to start & run.m reloads Of packages

nrjank
> Q.: Can anybody confirm this?
>
I have noticed a few times in the last couple weeks that Octave (5.1.0
on Windows 10) takes a long time (a minute or more) to load. But it
seems inconsistent, and I'm on a managed system, so rarely had a
reason to try to pin it on octave. Would be nice to learn that it is
related to an Octave side sensitivity that could be eliminated


> Q.: If confirmed, what is the cause, and does Octave work as it should?

that said, any time i do notice the delay, I have noticed no problems
running octave when it finally comes up. I have no idea at this point
how to try to pinpoint any cause when it does come up, if it would be
repeatable enough to debug somehow.  again, managed system, so admin
side things like event viewer aren't generally available without
external intervention. (not a time investment i'm keen on).

only other delays I've notice in Octave are when changing folders it
can sometimes take a very long time for octave to respond as (I
believe) the file browser window parses the file list in a large
folder.  This is much longer than the native file browser (from, say,
a Save As in the Editor) takes to do the same thing. I expect this is
a separate issue, and hasn't been annoying enough for me to raise it
to bug level concern.

Reply | Threaded
Open this post in threaded view
|

Re: Octave on Windows takes a long time to start & run.m reloads Of packages

John W. Eaton
Administrator
In reply to this post by PhilipNienhuis
On 2/2/20 1:18 PM, PhilipNienhuis wrote:

> While running __run_test_suite__ with a freshly cross-built Octave-6.0.0 on
> Windows, I saw a FAIL in run.m.
> That FAIL has been there for quite some time, didn't bother, "test run.m"
> works fine when run outside of __run_test_suite__.
>
> But because since one or two days Octave on Windows suddenly takes a very
> long time to load I added some tic/toc statements in
> chk_spreadsheet_support.m, invoked by __init_io__.m, in turn invoked by
> PKG_ADD in the io package, to find out if loading Java classes for
> LibreOffice would take so long. I saw no strange things there, finding &
> loading loading the .jars takes altogether ~5-6 seconds of in total 25
> seconds for he gUI to appear until the prompt is shown.

Can you bisect and determine which changeset caused the difference in
behavior?

If it is something that happened recently, maybe it is an unintended
side effect of this change:

   http://hg.savannah.gnu.org/hgweb/octave/rev/262cdfc6faf9

which made the load_path class use the absolute canonical directory name
as the key for the private function map?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Octave on Windows takes a long time to start & run.m reloads Of packages

PhilipNienhuis
John W. Eaton wrote:

> On 2/2/20 1:18 PM, PhilipNienhuis wrote:
>> While running __run_test_suite__ with a freshly cross-built
>> Octave-6.0.0 on
>> Windows, I saw a FAIL in run.m.
>> That FAIL has been there for quite some time, didn't bother, "test run.m"
>> works fine when run outside of __run_test_suite__.
>>
>> But because since one or two days Octave on Windows suddenly takes a very
>> long time to load I added some tic/toc statements in
>> chk_spreadsheet_support.m, invoked by __init_io__.m, in turn invoked by
>> PKG_ADD in the io package, to find out if loading Java classes for
>> LibreOffice would take so long. I saw no strange things there, finding &
>> loading loading the .jars takes altogether ~5-6 seconds of in total 25
>> seconds for he gUI to appear until the prompt is shown.
>
> Can you bisect and determine which changeset caused the difference in
> behavior?
>
> If it is something that happened recently, maybe it is an unintended
> side effect of this change:
>
>    http://hg.savannah.gnu.org/hgweb/octave/rev/262cdfc6faf9
>
> which made the load_path class use the absolute canonical directory name
> as the key for the private function map?

Sure, I'll do. This started to happen very recently, just a few days ago.
It is most conspicuously in the chk_spreadsheet_support.m function in
the io package that helps to load Java classes or spreadsheet I/O. I'll
start with running it through the profiler.

Philip



Reply | Threaded
Open this post in threaded view
|

Re: Octave on Windows takes a long time to start & run.m reloads Of packages

PhilipNienhuis
PhilipNienhuis wrote

> John W. Eaton wrote:
>> On 2/2/20 1:18 PM, PhilipNienhuis wrote:
>>> While running __run_test_suite__ with a freshly cross-built
>>> Octave-6.0.0 on
>>> Windows, I saw a FAIL in run.m.
>>> That FAIL has been there for quite some time, didn't bother, "test
>>> run.m"
>>> works fine when run outside of __run_test_suite__.
>>>
>>> But because since one or two days Octave on Windows suddenly takes a
>>> very
>>> long time to load I added some tic/toc statements in
>>> chk_spreadsheet_support.m, invoked by __init_io__.m, in turn invoked by
>>> PKG_ADD in the io package, to find out if loading Java classes for
>>> LibreOffice would take so long. I saw no strange things there, finding &
>>> loading loading the .jars takes altogether ~5-6 seconds of in total 25
>>> seconds for he gUI to appear until the prompt is shown.
>>
>> Can you bisect and determine which changeset caused the difference in
>> behavior?
>>
>> If it is something that happened recently, maybe it is an unintended
>> side effect of this change:
>>
>>    http://hg.savannah.gnu.org/hgweb/octave/rev/262cdfc6faf9
>>
>> which made the load_path class use the absolute canonical directory name
>> as the key for the private function map?
>
> Sure, I'll do. This started to happen very recently, just a few days ago.
> It is most conspicuously in the chk_spreadsheet_support.m function in
> the io package that helps to load Java classes or spreadsheet I/O. I'll
> start with running it through the profiler.

Some profiling results from a version built Jan 29 (still fast) and Jan 31
(slow), in attached .png.
(sorry for that, it's a bit hard to copy tables into Nabble, otherwise it
would be html.)
In between those dates the slowdown took place.
I also tried with Octave-5.1.0, that is still a bit faster than dev Octave
of the end of last January.
<https://octave.1599824.n4.nabble.com/file/t248596/chk_spr-supp_timings.png>
It turns out that especially string functions take much longer to execute
(some in the order of 50 times slower). That could be due to the functions
themselves but it can be equally probably due to the variable content they
are applied to. I still have to sort out the latter, TTBOMK most of it is
javaclasspath contents, path stuff and some calls to dir.m.
chk_spreadsheet_support.m is a fairly complex function and I have little
time until Friday so I have to see how far I get.

FTR, if I do not load the io package, starting up Octave (incl. mapping,
geometry/matgeom, windows, signal/control and linear-algebra packages) seems
about as fast as it has always been the last years.

Philip




--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Octave on Windows takes a long time to start & run.m reloads Of packages

PhilipNienhuis
In reply to this post by John W. Eaton
John W. Eaton wrote

> On 2/2/20 1:18 PM, PhilipNienhuis wrote:
>> While running __run_test_suite__ with a freshly cross-built Octave-6.0.0
>> on
>> Windows, I saw a FAIL in run.m.
>> That FAIL has been there for quite some time, didn't bother, "test run.m"
>> works fine when run outside of __run_test_suite__.
>>
>> But because since one or two days Octave on Windows suddenly takes a very
>> long time to load I added some tic/toc statements in
>> chk_spreadsheet_support.m, invoked by __init_io__.m, in turn invoked by
>> PKG_ADD in the io package, to find out if loading Java classes for
>> LibreOffice would take so long. I saw no strange things there, finding &
>> loading loading the .jars takes altogether ~5-6 seconds of in total 25
>> seconds for he gUI to appear until the prompt is shown.
>
> Can you bisect and determine which changeset caused the difference in
> behavior?
>
> If it is something that happened recently, maybe it is an unintended
> side effect of this change:
>
>    http://hg.savannah.gnu.org/hgweb/octave/rev/262cdfc6faf9
>
> which made the load_path class use the absolute canonical directory name
> as the key for the private function map?

(sorry for coming back to this thread a bit late.)

Right, it is exactly that cset that makes the difference.

What else can I do to investigate? Would it help to open a bug report?

Philip




--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Octave on Windows takes a long time to start & run.m reloads Of packages

nrjank
On Sun, Feb 9, 2020 at 5:44 PM PhilipNienhuis <[hidden email]> wrote:
John W. Eaton wrote
> On 2/2/20 1:18 PM, PhilipNienhuis wrote:
>> While running __run_test_suite__ with a freshly cross-built Octave-6.0.0
>> on
>> Windows, I saw a FAIL in run.m.
>> That FAIL has been there for quite some time, didn't bother, "test run.m"
>> works fine when run outside of __run_test_suite__.
>>
>> But because since one or two days Octave on Windows suddenly takes a very
>> long time to load I added some tic/toc statements in
>> chk_spreadsheet_support.m, invoked by __init_io__.m, in turn invoked by
>> PKG_ADD in the io package, to find out if loading Java classes for
>> LibreOffice would take so long. I saw no strange things there, finding &
>> loading loading the .jars takes altogether ~5-6 seconds of in total 25
>> seconds for he gUI to appear until the prompt is shown.
>
> Can you bisect and determine which changeset caused the difference in
> behavior?
>
> If it is something that happened recently, maybe it is an unintended
> side effect of this change:
>
>    http://hg.savannah.gnu.org/hgweb/octave/rev/262cdfc6faf9
>
> which made the load_path class use the absolute canonical directory name
> as the key for the private function map?

(sorry for coming back to this thread a bit late.)

Right, it is exactly that cset that makes the difference.

What else can I do to investigate? Would it help to open a bug report?


Looking at still open bug #57439 tied to that cset [1], best might be to add a comment over there with an impact summary. 

Reply | Threaded
Open this post in threaded view
|

Re: Octave on Windows takes a long time to start & run.m reloads Of packages

PhilipNienhuis
nrjank wrote
> On Sun, Feb 9, 2020 at 5:44 PM PhilipNienhuis &lt;

> pr.nienhuis@

> &gt; wrote:
>
>> John W. Eaton wrote
>> > On 2/2/20 1:18 PM, PhilipNienhuis wrote:
>> >> While running __run_test_suite__ with a freshly cross-built
>> Octave-6.0.0
>> >> on
>> >> Windows, I saw a FAIL in run.m.
>> >> That FAIL has been there for quite some time, didn't bother, "test
>> run.m"
>> >> works fine when run outside of __run_test_suite__.
>> >>
>> >> But because since one or two days Octave on Windows suddenly takes a
>> very
>> >> long time to load I added some tic/toc statements in
>> >> chk_spreadsheet_support.m, invoked by __init_io__.m, in turn invoked
>> by
>> >> PKG_ADD in the io package, to find out if loading Java classes for
>> >> LibreOffice would take so long. I saw no strange things there, finding
>> &
>> >> loading loading the .jars takes altogether ~5-6 seconds of in total 25
>> >> seconds for he gUI to appear until the prompt is shown.
>> >
>> > Can you bisect and determine which changeset caused the difference in
>> > behavior?
>> >
>> > If it is something that happened recently, maybe it is an unintended
>> > side effect of this change:
>> >
>> >    http://hg.savannah.gnu.org/hgweb/octave/rev/262cdfc6faf9
>> >
>> > which made the load_path class use the absolute canonical directory
>> name
>> > as the key for the private function map?
>>
>> (sorry for coming back to this thread a bit late.)
>>
>> Right, it is exactly that cset that makes the difference.
>>
>> What else can I do to investigate? Would it help to open a bug report?
>>
>>
> Looking at still open bug #57439 tied to that cset [1], best might be to
> add a comment over there with an impact summary.
>
> [1]  http://savannah.gnu.org/bugs/?57439

Thanks, I added a comment there.
Philip



--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html