156
edits
Projects: Difference between revisions
Jump to navigation
Jump to search
collecting profiler enhancement project ideas under single header
ArunGiridhar (talk | contribs) (→Numerical: removed a project that is already implemented in Octave) |
(collecting profiler enhancement project ideas under single header) |
||
| Line 111: | Line 111: | ||
**Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors). | **Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors). | ||
**Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals). | **Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals). | ||
== GUI Variable Editor and Property Inspector == | == GUI Variable Editor and Property Inspector == | ||
| Line 458: | Line 457: | ||
=Performance= | =Performance= | ||
* Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this. | * Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this. | ||
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance. | * Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance. | ||
| Line 535: | Line 533: | ||
** RESOLUTION | ** RESOLUTION | ||
* Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences. | * Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences. | ||
=Profiler Enhancement= | |||
Octave has a built in {{manual|profile|profiler}} thanks to a [[Summer of Code#GSoC 2011 | successful 2011 GSOC project by Daniel Kraft]]. But it really could use: | |||
* Better granularity: | |||
** It aggregates all calls to a function within at each level of the code, providing no way to know which call to a function might be more 'expensive'. | |||
** It aggregates all non-function-call overhead into time spent on 'self' without further detail to the user on what might be causing that overhead. | |||
** Associating time spent/function call count to line number would be a big plus. | |||
* A better interface. | |||
** The current CLI tool is good at determining time spent on function calls, providing both a summary output with {{manual|profshow}} and an interactive prompt that lets you dive down levels in the code with {{manual|profexplore}}. But this suffers from the aggregation limits mentioned above. | |||
** The profiler was written before the stable Octave GUI was released with Octave 4.0. This GUI now includes a built in editor with hooks to the interpreter. Better integration of the profiler output to the Octave GUI would be a significant functional improvement. (Current GUI integration is limited to an indicator light that shows the profiler is running.) | |||
** Enhancements are not strictly limited to using the current Octave GUI/Editor. Whatever helps users connect execution time to code location would be good. | |||
=Bugs= | =Bugs= | ||