| blob | be63662b7553c2a91aaa54faf68c83f65ed945c2 |
2 <html>
3 <head>
11 </head>
12 <body>
15 </div>
18 </div>
20 <ul><li>
22 <ul><li>
24 </li><li>
26 </li><li>
28 </li></ul>
29 </li><li>
31 <ul><li>
33 <ul><li>
35 </li><li>
37 </li><li>
39 </li></ul>
40 </li><li>
42 </li><li>
44 </li><li>
46 </li></ul>
47 </li><li>
49 <ul><li>
51 </li></ul>
52 </li><li>
54 </li><li>
56 </li><li>
58 </li><li>
60 </li></ul>
61 </div>
63 <p>
64 LuaJIT has an integrated statistical profiler with very low overhead. It
65 allows sampling the currently executing stack and other parameters in
66 regular intervals.
67 </p>
68 <p>
69 The integrated profiler can be accessed from three levels:
70 </p>
71 <ul>
76 </ul>
79 <p>
80 The bundled high-level profiler offers basic profiling functionality. It
81 generates simple textual summaries or source code annotations. It can be
84 </p>
85 <p>
86 To cut to the chase — run this to get a CPU usage profile by
87 function name:
88 </p>
90 luajit -jp myapp.lua
91 </pre>
92 <p>
94 possible option or to cater for special profiling needs. The low-level
95 profiler APIs are documented below. They may be used by third-party
96 authors to implement advanced functionality, e.g. IDE integration or
97 graphical profilers.
98 </p>
99 <p>
100 Note: Sampling works for both interpreted and JIT-compiled code. The
101 results for JIT-compiled code may sometimes be surprising. LuaJIT
102 heavily optimizes and inlines Lua code — there's no simple
103 one-to-one correspondence between source code lines and the sampled
104 machine code.
105 </p>
108 <p>
110 When the application run by the command line terminates, the profiler
113 </p>
114 <p>
116 performed:
117 </p>
118 <ul>
120 This is the default mode.</li>
140 Note: The actual sampling precision is OS-dependent.</li>
141 </ul>
142 <p>
144 spots in the application. Increasing the stack dump depth with (say)
146 hotspots. But sample aggregation is still flat per unique stack dump.
147 </p>
148 <p>
149 To get a two-level view (split view) of callers/callees, use
151 level are relative to the first level.
152 </p>
153 <p>
154 To see how much time is spent in each line relative to a function, use
156 </p>
157 <p>
158 To see how much time is spent in different VM states or
160 </p>
161 <p>
164 spent in a VM state or zone vs. hotspots. This can be used to answer
165 questions like "Which time consuming functions are only interpreted?" or
166 "What's the garbage collector overhead for a specific function?".
167 </p>
168 <p>
169 Multiple options can be combined — but not all combinations make
171 deep in 4ms intervals and shows a split view of the CPU consuming
172 functions and their callers with a 1% threshold.
173 </p>
174 <p>
176 always flat and at the line level. Obviously, the source code files need
177 to be readable by the profiler script.
178 </p>
179 <p>
180 The high-level profiler can also be started and stopped from Lua code with:
181 </p>
183 require("jit.p").start(options, output)
184 ...
185 require("jit.p").stop()
186 </pre>
189 <p>
190 Zones can be used to provide information about different parts of an
191 application to the high-level profiler. E.g. a game could make use of an
193 organized as a stack.
194 </p>
195 <p>
197 </p>
199 local zone = require("jit.zone")
200 </pre>
201 <ul>
204 returns its name.</li>
207 </ul>
208 <p>
211 </p>
214 <p>
216 profiler from Lua code. This module needs to be loaded explicitly:
218 local profile = require("jit.profile")
219 </pre>
220 <p>
221 This module can be used to implement your own higher-level profiler.
222 A typical profiling run starts the profiler, captures stack dumps in
223 the profiler callback, adds them to a hash table to aggregate the number
224 of samples, stops the profiler and then analyzes all of the captured
225 stack dumps. Other parameters can be sampled in the profiler callback,
226 too. But it's important not to spend too much time in the callback,
227 since this may skew the statistics.
228 </p>
232 <p>
234 string holding options:
235 </p>
236 <ul>
241 Note: The actual sampling precision is OS-dependent.
242 </li>
243 </ul>
244 <p>
248 state that holds the stack to sample for profiling. Note: do
250 </p>
251 <p>
253 callback (usually 1).
254 </p>
255 <p>
257 triggered. This may or may not correspond to the state of the VM when
261 compiler.
262 </p>
266 <p>
267 This function stops the profiler.
268 </p>
272 <p>
273 This function allows taking stack dumps in an efficient manner. It
276 </p>
277 <ul>
279 only the file name is used.</li>
281 use module:line.</li>
285 frame.</li>
287 </ul>
288 <p>
290 at the topmost frame of the thread. A negative number dumps the frames in
291 inverse order.
292 </p>
293 <p>
294 The first example prints a list of the current module names and line
295 numbers of up to 10 frames in separate lines. The second example prints
296 semicolon-separated function names for all frames (up to 100) in inverse
297 order:
298 </p>
302 </pre>
305 <p>
306 The profiler can be controlled directly from C code, e.g. for
309 </p>
313 <p>
316 </p>
317 <p>
319 declaration:
320 </p>
322 typedef void (*luaJIT_profile_callback)(void *data, lua_State *L,
323 int samples, int vmstate);
324 </pre>
325 <p>
327 state that holds the stack to sample for profiling. Note: do
331 </p>
335 <p>
336 This function stops the profiler.
337 </p>
341 <p>
342 This function allows taking stack dumps in an efficient manner.
345 </p>
346 <p>
349 argument returns the length of the output string. The buffer is
350 overwritten on the next call and deallocated when the profiler stops.
351 You either need to consume the content immediately or copy it for later
352 use.
353 </p>
355 </div>
360 ·
362 </span>
363 </div>
364 </body>
365 </html>