github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-15 20:54:54 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #16004] app/ui: unnecessary JSON re-parsing and missing memo dependencies in message components #87878

New Issue
Open
opened 2026-05-10 06:29:48 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-10 06:29:48 -05:00
Owner
Copy Link

Originally created by @matteocelani on GitHub (May 6, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/16004

What is the issue?

Several small performance issues across the message rendering pipeline add up, especially in chats with many tool calls:

  1. Tool call arguments are re-parsed on every render — BrowserToolCallDisplay calls JSON.parse on tool call arguments during render without memoizing the result. Every re-render (e.g., during streaming) re-parses the same JSON.

  2. Collapsed tool results still run JSON.stringify — When a tool result is collapsed and invisible, the component still stringifies the raw JSON on every render. This should be deferred until the user actually expands the section.

  3. Message memo comparator is missing lastToolQuery — The custom React.memo comparator for the Message component doesn't include lastToolQuery in the comparison, which can cause missed memoization opportunities or stale renders.

  4. lastToolQueries recalculates on every streaming token — The memoized computation depends on the full messages array reference, which changes on every streamed token. Using messages.length as the dependency would prevent unnecessary recalculations since tool queries only change when new messages are added.

  5. Unreachable code after early returns — In ToolCallDisplay, there's a code path that checks for browser.* tool names that can never be reached because a previous branch already handles all non-browser.* names and returns.

  6. browserToolResult prop is untyped — The prop is typed as any in MessageList instead of using the existing BrowserToolResult type.

Relevant log output

OS

macOS

GPU

Apple

CPU

Apple

Ollama version

No response

Originally created by @matteocelani on GitHub (May 6, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/16004 ### What is the issue? Several small performance issues across the message rendering pipeline add up, especially in chats with many tool calls: 1. **Tool call arguments are re-parsed on every render** — `BrowserToolCallDisplay` calls `JSON.parse` on tool call arguments during render without memoizing the result. Every re-render (e.g., during streaming) re-parses the same JSON. 2. **Collapsed tool results still run JSON.stringify** — When a tool result is collapsed and invisible, the component still stringifies the raw JSON on every render. This should be deferred until the user actually expands the section. 3. **Message memo comparator is missing `lastToolQuery`** — The custom `React.memo` comparator for the `Message` component doesn't include `lastToolQuery` in the comparison, which can cause missed memoization opportunities or stale renders. 4. **`lastToolQueries` recalculates on every streaming token** — The memoized computation depends on the full `messages` array reference, which changes on every streamed token. Using `messages.length` as the dependency would prevent unnecessary recalculations since tool queries only change when new messages are added. 5. **Unreachable code after early returns** — In `ToolCallDisplay`, there's a code path that checks for `browser.*` tool names that can never be reached because a previous branch already handles all non-`browser.*` names and returns. 6. **`browserToolResult` prop is untyped** — The prop is typed as `any` in `MessageList` instead of using the existing `BrowserToolResult` type. ### Relevant log output ```shell ``` ### OS macOS ### GPU Apple ### CPU Apple ### Ollama version _No response_
GiteaMirror added the bug label 2026-05-10 06:29:48 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#87878
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?