← diagnostics package

WithProfiler

Run the given computational graph with profiling enabled.

This will record information some performance metric of the graph that is wired into this node, such as CPU timing or memory usage. Note that not all profilers support all metrics. The profile will be written to a location specified by the "destination" property, but note that some profilers instead host a TCP server that one may connect to with an external tool in order to record profiling information inside the tool. Note that profiling incurs significant performance overhead (except for python:time) and should therefore not be enabled permanently in a pipeline. Another best practice is to judiciously limited the amount of computation that is being profiled, either by running on a smaller problem or profiling only a relevant subgraph, since large profile traces can lead to long running times, long results load times, or hit limits such a file sizes or memory usage in the tool used to view the profile results. For documentation on how to use the output generated by the respective profiler, please review the web documentation of the chosen profiler. By default this node will run the entire graph that is wired into it under the given context. However, you can also tag a subgraph that shall run under the given context by placing a dummy Placeholder node in your graph, giving it a unique slotname (one would usually name it "with" as a reminder that it pairs with a downstream "With..." node), and then and selectively wiring that placeholder's update output port to select nodes of your graph. Then only the nodes downstream of that placeholder will run under the given context. You will also need to set the "Graph [tag]" option (graph__signature in code) to name the tag that you used (e.g. "(with)" in this example). Version 0.8.0

Ports/Properties

graph

Computation to profile.

• verbose name: Graph
• default value: None
• port type: GraphPort
• value type: Graph

graph__signature

Optionally the slotname of a Placeholder node that shall mark the starting point of the graph that runs under the with context. As with all "With" context manager nodes in NeuroPype, the graph that runs under the context managed by this node is preceding the context manager node in the graph, rather than following it. This is accomplished by wiring the final node of the graph that shall execute under the governance of the context manager into the "graph" input port of the subsequent "With" node. In graphical UIs, this edge will be drawn in dotted style to indicate that this is not normal forward data flow where first the preceding node executes and then the subsequent node receives its output, but that instead the subsequent node (the context manager) receives a portion of the preceding graph, which it then runs in such a way that the context applies. You can use a "tilde" binding, spelled as (~), which affects the same nodes that a then or else branch in an IfElse node would control, which is normally what one would expect. However, note that this can have sometimes the unexpected consequence that simply wiring a value into your graph may "infect" an upstream portion of the graph with unintentionally running under the context, too. As an alternative, you can instead rely on a named Placeholder node to mark the beginning of the managed graph. The typical way to do this is to list a single placeholder name, e.g., (with), and then to create a Placeholder in your graph whose slotname is set to "with". Then, only the nodes that are downstream of (i.e., formally depending on) that placeholder will run under the context defined by the "With" node. In this case you need to make everything that shall be part of the context dependent on the placeholder, which can be accomplished by wiring the update output port of the Placeholder into the update input port of any nodes that shall run under the context (this dependency propagates down the graph, so you don't need to wire it to every node, just to the first node(s) that you want to be part of the context). Any nodes in this graph that have a backend and/or precision argument set to "keep" will be overridden by the backend and/or precision setting of this node.

• verbose name: Graph [Tag]
• default value: (~)
• port type: Port
• value type: object (can be None)

result

Result of the computation.

• verbose name: Result
• default value: None
• port type: DataPort
• value type: object (can be None)
• data direction: OUT

profiler

Profiler to use. Profilers are specific to the compute backend of interest and mainly focus on computations performed on that backend. The python backend covers all CPU-side computation. The jax backend applies to specifically to computations run under the control of the DeepModel, ConvexModel, and Inference nodes, and were that backend was chosen by the user in a node that supports it (e.g., WithBackend, etc). The other backends likewise mainly apply to computations where the user manually selected the backend in a node that supports it. With all options except python:time you will generally need an external tool to view the results. The options are formatted according to the backend of interest, followed by :, followed by the name of the a profiler available for that backend (and optionally profiler-specific options in () brackets as described in the following):

• The python:time profiler is a lightweight feature that simply measures the total time it takes to run the graph.
• The python:cProfile profiler generates a trace file of the execution time spent in different subroutines (incl. nodes) executed during the run of the graph; the result can be viewed with programs such as QCacheGrind and various other tools.
• The jax:trace profiler is the default profiler for JAX (jax.profiler.trace), which can generate a trace file of GPU compute and memory usage and running times that can be viewed with the TensorBoard profiler. One may optionally pass a True or False value in to control whether to additionally generate a trace file that can be loaded into the Perfetto visualizer (ui.perfetto.dev). When the "with memory" option is checked, an additional device memory profile will be written to a file in the same directory as the trace file that can be viewed using Google's pprof tool.
• The jax:server profiler instead opens a server socket, listening on the specified port (first argument), for the duration of the run of the wired-in graph that can be connected to while the WithProfiler node is executing. This is done from within an external program such as either the jax.collect_profile module (see online documentation), or TensorBoard's "capture profile" feature. This is mainly a workflow difference; what is being traced is the same as with the trace profiler.
• The torch:profile option is the default profiler for PyTorch, which generates a trace file that can be viewed with TensorBoard; this will mainly capture activity using the PyTorch backend (applicable where the user manually selected the torch backend in nodes that support it).
• The tensorflow:Profile option is the default profiler for TensorFlow, and generates a trace file that can be viewed with TensorBoard.

• verbose name: Profiler
• default value: python:time
• port type: ComboPort
• value type: str (can be None)

with_shapes

Hint to include shape information. Note that some profilers will always include shape information and others do not support it.

• verbose name: With Shapes
• default value: False
• port type: BoolPort
• value type: bool (can be None)

with_memory

Hint to include memory profiling information. Note that some profilers will always include memory profiling, and other profilers do not support it.

• verbose name: With Memory
• default value: False
• port type: BoolPort
• value type: bool (can be None)

with_stack

Hint to include stack trace information. Note that some profilers will always include stack trace information and others do not support it.

• verbose name: With Stack
• default value: False
• port type: BoolPort
• value type: bool (can be None)

destination

Profile destination. Note that some profilers will treat this as a directory, while others will create a file of the specified name.

• verbose name: Destination
• default value: ~/.neuropype/profile/%Y%m%d_%H%M%S.profile
• port type: StringPort
• value type: str (can be None)

is_global

If True, the context implicitly applies to the entire graph (except for those parts that are configuring the context itself). In this case the node must not have anything wired into its graph input and must not have any successors.

• verbose name: Is Global
• default value: False
• port type: BoolPort
• value type: bool (can be None)

set_breakpoint

Set a breakpoint on this node. If this is enabled, your debugger (if one is attached) will trigger a breakpoint.

• verbose name: Set Breakpoint (Debug Only)
• default value: False
• port type: BoolPort
• value type: bool (can be None)

metadata

User-definable meta-data associated with the node. Usually reserved for technical purposes.

• verbose name: Metadata
• default value: {}
• port type: DictPort
• value type: dict (can be None)