pmc(3) is a performance measurement framework for FreeBSD which uses the hardware performance measurement counters in modern CPUs to provide low-overhead, non-intrusive, system-wide measurement of production systems.

The project consists in creating a graphical user interface (GUI) analysis tool. It will be based on the performance monitoring counters framework pmc(3) and pmclog(3), using in-cpu measurement counters. The PMC GUI will allow a visual detection of performance bottlenecks in the execution of a program.

Management / welcome screen: The user associates PMCs (measurements) and processes. A set of allowed measurements i.e. according to the CPU - will be proposed to the user. Target processes can be selected by mouse.

Display/monitoring: The user can see in realtime what is happening. Profiling will concern selected processes, threads, and children or descendant processes. Spots/rectangles will correspond to a code segment. There will be a time view of the spots, with 1-2-3D graphes and color codes. Eventually, an interactive link to the function or code of the program should be implemented.

Before July, 22:

• Put initial modelable scaffold of UI
• Bring pmc(3)
• Put an initial grapher

TBD:

• make a port
• …

Stale: It's mostly in python and c, and is event driven (asynchronous). The GUI itself use wxPython. The program use FreeBSD specific and non FreeBSD specific system calls. A makefile generate a quick and dirty python module to pmc(3). It can be a good idea to simulate pmc_read() output in a first time. See for more details, and discussion.

A port is not done yet, but you can use pkg_add -r py24-wxPython py24-freebsd py24-ezpyinline for dependencies.

A main event loop [G] manage user interface events (mouse and keyboard events) and other workers. One thread [S] get every second the state of the system, eg active processes that can be bound to. One thread [P] get pmc data. One thread [V] build images every 1/25s. [G] can create or kill workers, but have readonly access to the data they generate. [V] have readonly access to [S] and [P] generated data.

After discussions with my mentor, I reverted to an initial idea of using Enlightenment API(s), with the following advantages/disadvantages:

• Lake of documentation as good as wxPython's
• BSD Licensing
• Easier integration of pmc(3)
• Scripting-like prototyping user interface (Edje)

Overview of APIs: http://www.enlightenment.org/p.php?p=docs&l=en

Edje book: http://enlightenment.sourceforge.net/docs/edjebook.html

Edje is a complex graphical design & layout library.

Edje internally holds a geometry state machine and state graph of what is visible, not, where, at what size, with what colors etc. This is described to Edje from an Edje .eet file containing this information. These files can be produced by using edje_cc to take a text file (a .edc file) and “compile” an output .eet file that contains this information, images and any other data needed.

Edje doesn't pretend to do containing and regular layout like a widget set. It still inherits the more simplistic layout ideas behind Ebits, but it now does them a lot more cleanly, allowing for easy expansion, and the ability to cover much more ground than Ebits ever could. For the purposes of Enlightenment 0.17, Edje should serve all the purposes of creating visual elements (borders of windows, scrollbars, etc.) and allow the designer the ability to animate, layout and control the look and feel of any program using Edje as its basic GUI constructor. This library allows for multiple collections of Layouts in one file, sharing the same image database and thus allowing a whole theme to be conveniently packaged into 1 file and shipped around.

Edje, unlike Ebits, separates the layout and behavior logic. Edje files ship with an image database, used by all the parts in all the collections to source graphical data. It has a directory of logical part names pointing to the part collection entry ID in the file (thus allowing for multiple logical names to point to the same part collection, allowing for the sharing of data between display elements). Each part collection consists of a list of visual parts, as well as a list of programs. A program is a conditionally run program that if a particular event occurs (a button is pressed, a mouse enters or leaves a part) will trigger an action that may affect other parts. In this way a part collection can be “programmed” via its file as to hilight buttons when the mouse passes over them or show hidden parts when a button is clicked somewhere etc. The actions performed in changing from one state to another are also allowed to transition over a period of time, allowing animation.

This separation and simplistic event driven style of programming can produce almost any look and feel one could want for basic visual elements. Anything more complex is likely the domain of an application or widget set that may use Edje as a convenient way of being able to configure parts of the display.

(adaptation of http://docs.enlightenment.org/api/edje/html/index.html)

(to be continued)

mprevot@freebsd.org http://blogs.freebsdish.org/mprevot/