#Framework Performance Profiling

Framework performance profiling helps identify the cost of component rendering and updates. This page covers ReactLynx's built-in instrumentation for tracing component rendering, diffing, and state updates.

#Overview

When profiling is enabled, ReactLynx automatically instruments the following operations:

#Enabling Profiling

Profiling is automatically enabled when the Lynx engine's profile recording is active. ReactLynx checks lynx.performance.isProfileRecording() at runtime to determine whether to enable profiling instrumentation.

To start profiling, you need to enable profile recording in the Lynx engine. For detailed instructions on how to record and view traces, see Recording Traces.

The instrumentation also has to be compiled into the bundle in the first place.

#Compiling the instrumentation into the bundle

ReactLynx ships built-in trace points for a component's render and diff, which show how components are rendered and diffed.

• In development (npx rsbuild dev), they are added by default.
• In production (npx rsbuild build), they are removed by default.

#Turning them on for a production build

Set performance.profile to true. This is useful when trying to optimize the performance of the application.

import { pluginLynx } from '@lynx-js/rsbuild-plugin';
import { defineConfig } from '@rsbuild/core';

export default defineConfig({
  plugins: [
    pluginLynx({
      performance: {
        profile: true,
      },
    }),
  ],
});

#Turning them off in development

Set performance.profile to false.

import { pluginLynx } from '@lynx-js/rsbuild-plugin';
import { defineConfig } from '@rsbuild/core';

export default defineConfig({
  plugins: [
    pluginLynx({
      performance: {
        profile: false,
      },
    }),
  ],
});

#Dynamic sampling with JS Profile

Use the JS Profile tool to collect call stack data at runtime, without changing the build configuration.

#Understanding Trace Events

#Render Traces

The ReactLynx::render::ComponentName trace measures the time spent executing your component's render function. This helps identify components with expensive render logic.

function ExpensiveComponent({ data }) {
  // This render function's execution time will be traced
  const processed = data.map((item) => complexCalculation(item));
  return (
    <view>
      {processed.map((item) => (
        <text>{item}</text>
      ))}
    </view>
  );
}

#Diff Traces

The ReactLynx::diff::ComponentName trace measures the time ReactLynx spends comparing the previous and new virtual DOM for a component. High diff times may indicate:

• Large component trees
• Frequent unnecessary re-renders
• Complex nested structures

#diffFinishNoPatch Traces

The ReactLynx::diffFinishNoPatch is an instant event that fires when a component finishes diffing but produces no patch. This event includes a componentName argument indicating which component's diff produced no changes.

This trace is useful for identifying unnecessary re-renders. If you see many diffFinishNoPatch events, it means components are frequently re-rendering but not actually producing any UI changes. This is an optimization signal that you may need to:

• Use React.memo or useMemo to prevent unnecessary re-renders
• Check if parent components are passing unstable props (e.g., creating new objects or functions on every render)
• Optimize state management to avoid unnecessary state updates

#setState Traces

The ReactLynx::setState trace is an instant event that marks when setState is called. It includes additional metadata:

• current state keys: Keys present in the current state
• next state keys: Keys present in the next state
• changed (shallow diff) state keys: Keys whose values changed

This helps you understand what triggered updates and which state properties changed.

#Flow ID Tracking

ReactLynx uses flow IDs to connect related trace events. When you call setState, a flow ID is generated and attached to all subsequent operations (diff, commit, patch) triggered by that state update. This allows you to trace the complete flow of an update through the system.

#Improving Component Name Readability

In production builds, component names may be minified and become unreadable (e.g., ReactLynx::render::t instead of ReactLynx::render::MyComponent).

To preserve readable component names, set the displayName property on your components:

function withDisplayName<T extends React.ComponentType<any>>(
  Component: T,
  name: string,
): T {
  Component.displayName = name;
  return Component;
}

// Function component
function MyComponent() {
  return <view />;
}
export default /* @__PURE__ */ withDisplayName(MyComponent, 'MyComponent');

// Class component
class MyClassComponent extends Component {
  render() {
    return <view />;
  }
}
export default /* @__PURE__ */ withDisplayName(
  MyClassComponent,
  'MyClassComponent',
);

// Function component
function MyComponent() {
  return <view />;
}
MyComponent.displayName = 'MyComponent';

// Class component
class MyClassComponent extends Component {
  static displayName = 'MyClassComponent';

  render() {
    return <view />;
  }
}

#Best Practices

1. Profile in realistic conditions: Test with production builds and realistic data to get accurate measurements.

2. Focus on hot paths: Pay attention to components that render frequently or handle large amounts of data.

3. Use displayName: Always set displayName for components you want to profile, especially in production builds.

4. Analyze flow IDs: Use flow IDs to understand the complete lifecycle of state updates, from setState to final patch.

5. Look for patterns: Identify components with consistently high render or diff times as optimization candidates.

#Related

• Rendering Process and Lifecycle
• Main Thread Script