Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Performance] Slow serialisation of callback responses

Abierto
  • ¿Algo no está bien?
#4,065 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@T4rk1n ya está trabajando en esto.

Desde el 14/10/2026.

  • #4067 de @T4rk1n — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

Start with to_json in dash's _utils module, which hands callback responses to plotly's to_json_plotly, and the orjson fallback path in plotly's JSON io module. Run the issue's timing snippet first to confirm the gap between the figure-only and figure-plus-Div cases. Done means a default= hook keeps the Div case close to the figure-only timing while the JSON output stays identical.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Labels: performance

Describe your context

dash                      4.1.0
plotly                    6.7.0
orjson                    3.11.9
pandas                    2.3.3
numpy                     2.3.5
  • Python 3.13. Server-side only; not browser related.

Describe the problem

Dash serialises every callback response with dash._utils.to_json, which hands the work to plotly's to_json_plotly. When orjson is installed, plotly first passes the whole response to orjson.dumps in a single call. If any value in the response is not orjson-native, orjson raises TypeError and plotly discards the attempt. Plotly then converts the entire payload in pure Python with clean_to_json_compatible and calls orjson.dumps a second time on the result.

Dash passes callback return values to to_json unconverted. A response therefore takes the slow path when it contains any of these:

  • a component, e.g. children=html.Div(...)
  • a go.Figure object, e.g. return fig
  • a value such as pd.Timestamp

Because the walk covers the whole response, it also visits every element of the figure's data, even though orjson could have serialised that data natively. Numeric numpy arrays are passed through the walk without being visited element by element, so most of the cost comes from figures built from plain Python lists of floats or datetimes.

The snippet below compares two callback responses. Both contain the same large figure of 10 traces x 20k points.

  • figure only: the figure is the only output. Every value is orjson-native, so orjson serialises it in one fast pass.
  • figure + html.Div: the same figure plus one extra output, a tiny html.Div("ok"). This mirrors a common callback that updates a graph and a status message.

The Div adds only a few bytes, so both responses should take about the same time to serialise. In practice the second is over 10x slower. The Div is not orjson-native, so it sends the whole response down the fallback path. All 200k figure values are walked in Python just to convert that one Div.

import time

import numpy as np
import plotly.graph_objects as go
import plotly.io
from dash import html
from dash._utils import to_json

plotly.io.json.config.default_engine = "orjson"
points = np.random.randn(20_000).tolist()  # plain Python list, as when data comes from a list or dataframe column
figure = go.Figure([go.Scatter(y=points) for _ in range(10)]).to_plotly_json()

for label, extra in [("figure only", {}), ("figure + html.Div", {"status": {"children": html.Div("ok")}})]:
    response = {"multi": True, "response": {"graph": {"figure": figure}, **extra}}
    start = time.perf_counter()
    to_json(response)
    print(f"{label}: {(time.perf_counter() - start) * 1000:.0f} ms")

Typical output: figure only: 7-10 ms and figure + html.Div: 100-118 ms.

The fallback cost depends on how the figure data was built. The table below repeats the same two responses for four common data types. Each row uses the same figure size of 10 traces x 20k points. Timings are the best of 3 runs of to_json. The right-hand column is the same response with the one tiny Div added.

figure data                 figure only   + html.Div
y = numpy array                  5 ms          6 ms
y = list of float                6 ms         93 ms
x = pd.DatetimeIndex            20 ms         99 ms
x = list of datetime            11 ms        456 ms

One small component makes the whole response roughly 5-40x slower to serialise. The numpy row is the exception, since the walk does not visit numpy arrays element by element. Returning a go.Figure object has the same effect as the Div. So does a pd.Timestamp anywhere in the response.

Expected behavior

Adding a small non-native value to a response should only add the cost of converting that one value. A tiny component returned alongside a large figure should therefore serialise in about the same time as the figure on its own.

Possible solution

Pass a default= callback to orjson.dumps. orjson calls it only for the values it cannot serialise, so the callback can convert just those values (for example with to_plotly_json()) while orjson handles everything else natively. This removes both the retry and the Python walk over the whole payload. In a quick prototype, responses containing a component or a pd.Timestamp serialised as fast as fully native ones, with identical JSON output.

The change could go in dash._utils.to_json or in plotly's to_json_plotly, which would also speed up fig.to_json().

A related note: without orjson installed, plotly falls back to the much slower stdlib json engine, and orjson is not a required dependency of dash. This may be worth mentioning in the performance docs.

Lenguaje dominante
Python
Estrellas
24.5k
Forks
2.3k
Merge medio
3 d 2 h
PR fusionados (30 d)
28

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de plotly/dash

Todos los issues de plotly/dash

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.