[Scilab-users] Scilab 6.1 too slow to list large vectors

[Perrichon]

Hello,

 


See also bugzilla  Scilab's Bug Tracker – Bug 16359

	

 

 

Time request : 100 s

 

Results :

Xcos Scilab 5.5.2 :

Durée de la simulation : 258.3 s

 

Xcos Scilab 6.1.0 :

Durée de la simulation : 4353.4 s

 

BR.

Pierre

 



 

Before printing, think about ENVIRONMENTAL responsabity

 

 

De : users <users-bounces at lists.scilab.org> De la part de Samuel Gougeon
Envoyé : mercredi 20 mai 2020 16:50
À : users at lists.scilab.org
Objet : Re: [Scilab-users] Scilab 6.1 too slow to list large vectors

 

Le 30/03/2020 à 11:56, Federico Miyara a écrit :


Dear All,

I have observed that Scilab 6.1 seems to have a regression respect to 6.0.2. Sometimes one forgets to put semicolon after the coputation of a vector with tens of thousands components. Scilab 6.0.2 listed all the components very fast. That was nice because one hadn't to cancel the computation, it took about 1 s. With 6.1 it takes much longer. For instance

Fs = 44100
T = 2.5
t = [0:T*Fs]/Fs;
ximp = exp(-t/0.3).*rand(t,"normal") + 0.004*rand(t,"normal");
 
tic
ximp = ximp(:)
toc
 

This takes 1.36 s in 6.0.2

The same code in 6.1 takes 182 s

Any idea why?

I know I can cancel at any moment the script execution, but if there were a process that took a lot of time one wouldn't be willing to stop it...

 

Apparently, the maximum number N of lines of the console scroll buffer set in the user preferences (by default to 3000) is not taken into account to abstract the display in this kind of situation. Is it?

Yet, if there is no opened diary, displaying 100000 "primary" rows looks 97% useless if the scroll buffer is 3000-row tall: 97000 rows will anyway become unreachable an lost, after the full display.

So, even without anticipating wrapping of long primary rows, that still multiplies the number of actual rows to display, wouldn't it be wise to limit the display to N primary lines, either the N last ones, or the N/2 first ones + "..." + the N/2 last ones ?

Even in the case of having so tall full diaries is required (that is a very specific and exceptional case), it is always possible to increase N through the preferences.

My two cents...

Samuel

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20200520/c609ddf5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 12352 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20200520/c609ddf5/attachment.jpg>