Ts '(<a:;1) { a' 0.00939758 525568

Ts '1 {"1 a' 0.00952329 525184

Integrated rank support in dyad { gives the two forms equal performance. Look what happens when we replace the { by a user-defined verb with the same function:

from =. {

Ts '(<a:;1) from a' 0.00953335 525760

Ts '1 from"1 a' 0.365966 525696

from lacks integrated rank support, even though it is defined to have the same function as {, and it suffers when it is applied to each 1-cell. This is a good reason for you to learn the J primitives and not replace them with mnemonic equivalents.

Shining a Light: The J Performance Monitor

A magnet makes it easy to pick up a needle, but it won't much help you find a needle in a haystack. Likewise, being able to time and tune individual sentences will not suffice to let you improve the performance of a large J program. A large program spends most of its time executing a small subset of its code, and any improvements you make to other areas are simply wasted effort. I remember a case where a 20,000-line assemblerlanguage program was spending 30% of its time executing a single machine instruction— and that instruction turned out to be unnecessary! What you need is a tool that will direct your attention to the areas where a speedup will really matter.

The J Performance Monitor will show you how much time is spent executing each line of your application. You can run the Lab on the Performance Monitor to see all the facilities available, or you can jump right into timing your code with the simple sequence

load 'jpm'

Do this once to load the tool. Then, for each timing run, execute start_jpm_ 1e7

357142

The operand of start_jpm_ is the size in bytes of the trace buffer, and the result is the number of trace entries that can fit in the buffer. A trace entry is added for each line executed, and for entry and exit of explicit definitions (i. e. verbs defined with

verb define).

run the code you want to time viewtotal_jpm_ "

J will display a popup window with information about the time spent in each verb. An example display is

122

The columns contain the following information: name the name of the verb

locale the locale the verb was running in (we will discuss locales in a later chapter)

all the amount of time spent in this verb including time spent in verbs called by this verb

here the amount of time spent in this verb but not including time spent in verbs called by this verb

here% the here time as a percentage of total time cum% cumulative total of here%

rep the number of times the verb was executed

You should focus your attention on the here column. If you see a verb that is taking

We see that line 13 takes the most time. Clicking on the column heading will sort the lines using that column as a key, making it easy for you to concentrate on the individual lines that are taking the most time.

You should be aware of one quirk. The Performance Monitor will account for the time spent in every line of a named verb that is explicitly defined (i. e. defined using verb define or 3 : or 4 :). Other verbs are accounted for only as a whole, not line-by-line. You may be surprised to find that a verb defined by

123

opaqueverb =: verb define"0 <definition here>

)

will not be treated line-by-line. Yes, there is an explicit definition, but opaqueverb is not that definition: opaqueverb is a compound produced by the rank conjunction " . If you want to look inside opaqueverb, you need to define it like so:

opaqueverb =: limpidverb"0 limpidverb =: verb define <definition here>

)

The J Performance Monitor makes it easy to give your code a good finish by pounding down the nails that are sticking up. As of J5.01a there are a few quirks you need to work around: you cannot have a verb with the same name as a locale; you must close a detail window before you create a new one; and time spent in explicit modifiers is not correctly accounted for.

124