octave-maintainers
[Top][All Lists]
Advanced

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

Re: Follow up on profiler development


From: Daniel Kraft
Subject: Re: Follow up on profiler development
Date: Tue, 09 Aug 2011 07:44:41 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/09/11 07:07, Jordi GutiƩrrez Hermoso wrote:
> Hello, Daniel. A number of things.
> 
> Can you in fact provide some gprof output (run a few demos or tests) 
> and make sure that the profiling code functions are all very low in 
> the profiling output? Let me know if you manage. I had some trouble 
> writing profiling instrumentation data into the Octave binary with 
> gprof, so I used oprof instead. If you also have trouble with gprof 
> try with oprof, but I would like some reassurance that we are not 
> slowing things down.

I'll try to do this after data collection for hierarchical profiles is
done; then the backend should be complete (in a first stage at least),
even if we still play around with the UI to hierarchical data.  And
thanks for the hints with gprof -- I'll try it, but if I fail I'll try
with oprof.

> On 8 August 2011 13:06, Daniel Kraft <address@hidden> wrote:
>> Basically, I'm thinking about an interactive command-line
>> interface to explore the call-tree. (Later, we could also think
>> about generating some output; like the Matlab HTML; or even 
>> gprof/callgrind data for use with those tools.)
> 
> The interactive interface is nice, but it's kinda nonstandard for 
> Octave core functions, and other than the demo functions, I can't 
> think of any other core Octave function that interactively requests 
> input from the user. This is not to mean this is undesirable, but 
> unusual. If you can do this easily (it's not too difficult to 
> implement this with m-scripts), go ahead, but don't lose sight of
> the goal to also have access to this data non-interactively and 
> programmatically.

Yes, as mentioned below the first step will actually be getting the data
programmatically as a kind of nested structures or cells.  Maybe I'll
just add this to the result profile('info') gives (and of course with
appropriate backend routines).

All UI stuff will then depend on this routine itself.

>> Note that here again, I will seperate the backend from the
>> interface -- i.e., make __profile_data or possibly a new function
>> return the tree as Octave data structure, and have profshow.m
>> interpret it and handle the interactive stuff. Thus, we can easily
>> change the interface or add new presentation options.
> 
> Okay, I assume you will do this first?

Yes.  See above -- I actually want the UI to use the programmatic
interface, so in fact I *have to* implement getting the data prior to
the interface. ;)

> 2011/8/5 Daniel Kraft <address@hidden>:
>> For now, I provide the attached patch (since it is still work in 
>> progress, I didn't commit it to my hg history and it's a raw
>> patch; hope that's ok). It would be really cool if someone had an
>> idea why is_defined() becomes false when I set the file-name. If
>> not, I'll try to figure that out myself.
> 
> This is beyond my expertise, and it's one of the things I wish other 
> Octave developers can help us out with. So I hope someone else can 
> provide some insights here. The guts of the interpreter are
> something I don't yet understand myself.

Ok -- I'll put that patch on hold for now, and welcome it if someone has
any idea!

Yours,
Daniel

- -- 
OpenPGP: 3BA2 3DDB 7758 F010 BDAB 0DCF 527E 79BA A3B5 3998
or use https://safesend.domob.eu/
- --
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOQMlIAAoJEFJ+ebqjtTmYDEQP/jMbGvG2Du0Inbqq1jvE6EF2
BQpJ5wyRXUmkB0xH++C3TSOcLNk25cve9VrMwKE0ZZ4B9lcceqzlK2QwNG99+Rju
wYawOYAkl7ROH1j6xdxgL+0aqeW83vCbIgGoR0HHWSfqannI2io/glWJZh2T8lCj
vFOuf8Iz7DLS+JCYTRSwey0Req8WAE2LDDAaTH+sN3+0FdOmCevcyomcQ+3L6R4/
3saSmIRzLfsz5EnptjJ6igOtU8vG5b8diLmmuaQLlkwCVPt1gvJCab9XiMwcjFmF
tuPZveSyLqkg3kPTfY7WYYrgbGre5S1BePjMPZFYXp8bkr2xRHQ0qBvlhUU9ff6u
nEt7nb8MKSCw4n6dRTzbYqx95U2BQ+g1yAxNFy2zURJZk58HWOMY+iaxQGgLhin0
p1VJbwTQHvygFngeTeVW0kU5kEfQ8YPdz2kapSlJsoXLamwgkgB2d6RQLFMvClAr
sfIRbd9jHeqTOK+a6RHyrVIqfvr+BbfBbVMtIzBLDcJtF4tlewEa3zgXKg779V6z
dHC2v5DH8jM9ICH7sOl2hwoQum5xypGxQTuZSboh8VgDAQougxn6kUCgfbYRpKEM
OBcdIQ6wo/xNAuSdA84h11x6Ws3W9Xk1PmchHznIw4USKik//U2fFw0wI/NZhQqe
+d4Cym37Mk8k+koT+57x
=1+Tq
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

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