[Scilab-Dev] SEP advanced function/profiling in Scilab 6

[Clément David]

Hello Samuel and thanks for your comments,

 

I updated the SEP with more information clarifying some aspects. These
`profile` functions are not supposed to replace the existing `coverage`
ones. The underlying execution counters are re-used for the two
implementations but the usage might slightly be different: produce a static
report for the coverage or display performance information while developing.
I reword some aspect to clarify the display and show methods, the
“instrumentation”

 

At first, I want to map the Scilab 5 features before trying to push
enhancement or API modification so I used similar names as in Scilab 5. The
main issue with switching API is the associated effort to port existing
Scilab 5 toolset to the new API. As you propose, a Matlab-like `profile`
might be a later extension.

 

Best,

 

--

Clément

 

 

From: dev <dev-bounces at lists.scilab.org> On Behalf Of Samuel Gougeon
Sent: Sunday, December 2, 2018 8:54 PM
To: List dedicated to the development of Scilab <dev at lists.scilab.org>
Subject: Re: [Scilab-Dev] SEP advanced function/profiling in Scilab 6

 

Hello Clément,

Glad to see that restoring handy profiling facilities is awake.
I am afraid i don't catch all from the SEP. Here is a short list of remarks
that still make me wondering:

*	In 5.5.2, the former functions were about BOTH coverage and timing.
Displaying both informations in the 2 first columns was very handy.
The current SEP seems to present 2 separated subsets of functions, as if
things are planned to become separated. This is quite unclear.
*	Reforging things should be a major opportunity to suppress the
splitting in many functions just vs the action.
Hence, the former add_profiling, remove_profiling, reset_profiling were
painfull because inventing, maintaining, documenting and using 3 separate
functions just because of ONE parameter is changing -- the action -- imo was
imo meaningless. This is a low-level kind of design, whereas Scilab is a
high-level language, the language should be integrated: I rather expect
using
profile(action, target [, options])  with for instance action =
"on"|"off"|"reset"|"disp"|"html"|"plot"...
In this way, things are open. If other actions have to be added latter, the
prototype won't change, and no need to have a Nth function and Nth
documentation page in 5 natural languages.
*	In the SEP, the fact that restoring a display in text mode in the
console is planned does not explicitly appear. Nor the planned order of
columns of results. Both aspects are really killing details. When improving
the code, i never felt the need of having pleasant colored reports. But,
daily, the display in console was my first and almost only usage.
*	"instrumentation" is some hardly understandable devs jargon.

Best regards

Samuel


Le 30/11/2018 à 15:02, Clément David a écrit :

Dear devs,
 
I started working on re-introducing profiling functions into Scilab 6.0;
these functions will behave very similarly to the Scilab 5 ones but have
been renamed for consistency and their arguments will slightly differs
(macro value vs macro as string). Thanks to Samuel's mail [2], I wrote a SEP
[1] that might finally fix that miss, please comment and give feedbacks !
 
[1]: https://wiki.scilab.org/SEP%20profiling%20in%20Scilab%206.1
[2]:
http://mailinglists.scilab.org/New-profiling-module-code-coverage-td4034048.
html
 
Thanks,
 
--
Clément






_______________________________________________
dev mailing list
dev at lists.scilab.org <mailto:dev at lists.scilab.org> 
http://lists.scilab.org/mailman/listinfo/dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181203/7c9c3e0c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4425 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181203/7c9c3e0c/attachment.p7s>