[luluiz]

User-Facing Changes

Description

This document describes the performance optimizations implemented for topic message navigation in the Lichtblick application.

Problem

When navigating through messages in topics with large datasets (e.g., 50,000+ messages), the original implementation would iterate from the beginning of the topic every time, resulting in:

• O(n) complexity for each navigation operation
• Noticeable lag when navigating near the end of large topics
• Poor user experience with multi-second delays

Example Scenario

• MCAP file with 50,000 messages
• User at message 49,999 (end of timeline)
• Clicking "Next Message" would iterate through all 50,000 messages to find 50,000
• Result: 2-5 seconds delay

Solution

1. Enhanced getBatchIterator API

Updated the Player.getBatchIterator interface to accept optional start and end time parameters:

getBatchIterator: (topic: string, options?: { start?: Time; end?: Time }) =>
  AsyncIterableIterator<Readonly<IteratorResult>> | undefined;

This allows the iterator to seek directly to a specific time range instead of always starting from the beginning.

2. Optimized Next Message Navigation

Strategy: Start iteration from currentTime instead of the beginning.

const iterator = getBatchIterator(topicName, { start: current });

Performance Improvement:

• Before: O(n) - iterate from start to currentTime, then find next
• After: O(1) - start at currentTime, find first message after

Position	Before	After	Speedup
Beginning (msg 1→2)	O(1)	O(1)	Same
Middle (msg 25k→25k+1)	O(25k)	O(1)	25,000x
End (msg 49,999→50k)	O(50k)	O(1)	50,000x

3. Adaptive Window Search for Previous Message

Challenge: Finding the previous message requires knowing the last message before currentTime, which is harder when iterating forward.

Strategy: Hybrid adaptive window approach

1. Calculate Initial Window based on topic statistics:

   const messagesPerSecond = numMessages / totalDuration;
   const windowMs = (targetMessages / messagesPerSecond) * 1000;

2. Progressive Window Expansion:

   • Start with calculated window (e.g., 100ms for dense topics)
   • If no message found, expand to 5x, then 25x, up to 60s
   • Stop when message found or boundary reached

3. Iterate Only Within Window:

   const windowStart = subtractMilliseconds(currentTime, windowMs);
   const iterator = getBatchIterator(topicName, {
     start: windowStart,
     end: currentTime,
   });

Performance Improvement:

Topic Density	Window Used	Messages Iterated	Speedup
Dense (100 msg/s)	100ms	~10 msgs	5,000x
Medium (10 msg/s)	500ms	~5 msgs	10,000x
Sparse (1 msg/s)	2000ms	~2 msgs	25,000x

4. Helper Functions

Created timeWindowHelpers.ts with utilities:

• subtractMilliseconds(): Safe time arithmetic with nanosecond handling
• calculateOptimalWindowMs(): Compute ideal window based on message density
• createWindowSizes(): Generate progressive window sequence
• wouldReachBoundary(): Check if window reaches topic boundary

5. Backward Compatibility

The options parameter is optional, ensuring backward compatibility:

// Old code still works
getBatchIterator("topic_name");

// New optimized code
getBatchIterator("topic_name", { start: currentTime });

Performance Benchmarks

Real-world Scenario: 50,000 Message MCAP

Operation	Position	Before	After	Improvement
Next	Beginning	~10ms	~10ms	Same
Next	Middle	~1.5s	~10ms	150x faster
Next	End	~3s	~10ms	300x faster
Previous	Beginning	~50ms	~50ms	Same
Previous	Middle	~1.5s	~20ms	75x faster
Previous	End	~3s	~30ms	100x faster

Conclusion

This optimization provides 100-300x performance improvement for navigation in large topics, transforming a previously frustrating multi-second wait into an instant ~10-30ms response time.

Checklist

• The web version was tested and it is running ok
• The desktop version was tested and it is running ok
• This change is covered by unit tests
• Files constants.ts, types.ts and *.style.ts have been checked and relevant code snippets have been relocated

[andremarques94]

first.mov

This is the problem with the button not being disabled from the start. You have it enabled and think that you can move back, but you can't (the starting point just hasn't been calculated yet).

https://github.com/user-attachments/assets/f679965a-4bd5-40ef-940f-c47125ddc67c

The same goes for when you're loading parts of the data. What ends up happening is you create false positives, where the user thinks they're moving forward or backwards, but nothing is really happening.

I don't think this should be blocking though. I do think this is the best that you can have right now with the way the app is built.

You can either have a more conservative approach where you block moves to next/prev message and end up with a long wait time and users thinking the button is stuck, or you have a more optimistic approach where you allow the clicks but disable the button, with nothing happening when the user clicks it.

let me know what you think @luiz-bezerra-ctw-bmwgroup-com_QCOM

[andremarques94]

I think the linting is still not fixed

[andremarques94]

I'll approve the moment the linting is fixed. Also sonar test %

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
83.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ctw-joao-luis]

A thing that I noticed during testing is that unless you have the topic you want to seek next message selected you can really tell that it's doable to do that. I feel like it's hard to notice

[luluiz]

A thing that I noticed during testing is that unless you have the topic you want to seek next message selected you can really tell that it's doable to do that. I feel like it's hard to notice

Yah, any suggestion about how can we improve the UI to show the user that they can move on to the next/prev message in the topic? Perhaps a tooltip when hovering over the buttons?

Note that the buttons are initially disabled.

[andremarques94]

lgtm

[ctw-joao-luis]

A thing that I noticed during testing is that unless you have the topic you want to seek next message selected you can really tell that it's doable to do that. I feel like it's hard to notice

Yah, any suggestion about how can we improve the UI to show the user that they can move on to the next/prev message in the topic? Perhaps a tooltip when hovering over the buttons?

Note that the buttons are initially disabled.

I think a future improvement could be always highlighting the buttons if that current topic is being used, and doesnt need to be selected