[GH-ISSUE #139] Browser performance issues when there are over 30,000 messages displayed. #114

New issue

Closed

opened 2026-02-26 05:31:22 +03:00 by kerem · 4 comments

kerem commented

2026-02-26 05:31:22 +03:00

Owner

Originally created by @jrthib on GitHub (Dec 11, 2014).
Original GitHub issue: https://github.com/NarrativeScience-old/log.io/issues/139

Proposed fix: Create a setting that rolls off older messages past a user specified limit.

Originally created by @jrthib on GitHub (Dec 11, 2014). Original GitHub issue: https://github.com/NarrativeScience-old/log.io/issues/139 **Proposed fix:** Create a setting that rolls off older messages past a user specified limit.

kerem closed this issue

2026-02-26 05:31:22 +03:00

kerem commented

2026-02-26 05:31:22 +03:00

Author

Owner

@nelsonomuto commented on GitHub (Sep 2, 2015):

I noticed this as well, we need a system that works for environments where > = 20 messages/sec are generated

@nelsonomuto commented on GitHub (Sep 2, 2015): I noticed this as well, we need a system that works for environments where > = 20 messages/sec are generated

kerem commented

2026-02-26 05:31:22 +03:00

Author

Owner

@nelsonomuto commented on GitHub (Sep 2, 2015):

@msmathers Something that I noticed works quite well and improves performance is changing the client message_cap to a lower number. For example I changed it to 1 and it really boosted performance, the difference was night and day.
Even at 200,000 messages there is no lag at all when the message_cap variable is reduced to 1!
As opposed to before with the previous cap at 5000 the page started crawling at ~ 20,000 messages and browser freezing at ~ 70,000 messages.

I analyzed the code and I don't see any use for having a larger message_cap, at least not in the current tag v0.3.4. My assumption is this is left over from a legacy feature. Otherwise, keeping the LogMessages backbone collection as small as possible tremendously improved the usability.

client.coffee line 26 v0.3.4
MESSAGE_CAP = 1

@nelsonomuto commented on GitHub (Sep 2, 2015): @msmathers Something that I noticed works quite well and improves performance is changing the client message_cap to a lower number. For example I changed it to 1 and it really boosted performance, the difference was night and day. Even at 200,000 messages there is no lag at all when the message_cap variable is reduced to 1! As opposed to before with the previous cap at 5000 the page started crawling at ~ 20,000 messages and browser freezing at ~ 70,000 messages. I analyzed the code and I don't see any use for having a larger message_cap, at least not in the current tag v0.3.4. My assumption is this is left over from a legacy feature. Otherwise, keeping the LogMessages backbone collection as small as possible tremendously improved the usability. client.coffee line 26 v0.3.4 MESSAGE_CAP = 1

kerem commented

2026-02-26 05:31:22 +03:00

Author

Owner

@nelsonomuto commented on GitHub (Sep 3, 2015):

I also think using canvas for the UI as opposed to DOM Elements will greatly improve the performance.
The lag is still there with my fix, I noticed at around 400K messages that the browser starts slowing down considerably.

I will explore using canvas to render the UI.

I know you may be thinking this will mean we cannot copy/paste logs. There is a solution for this: http://grassator.github.io/canvas-text-editor/

@nelsonomuto commented on GitHub (Sep 3, 2015): I also think using canvas for the UI as opposed to DOM Elements will greatly improve the performance. The lag is still there with my fix, I noticed at around 400K messages that the browser starts slowing down considerably. I will explore using canvas to render the UI. I know you may be thinking this will mean we cannot copy/paste logs. There is a solution for this: http://grassator.github.io/canvas-text-editor/

kerem commented

2026-02-26 05:31:22 +03:00

Author

Owner

@msmathers commented on GitHub (Jan 16, 2020):

v0.4x is a complete rewrite of the UI component using React 16, and thus has a completely new rendering mechanism that is likely more performant than backbone. No hard benchmarking has been done, so feel free to create any new issues around performance.

@msmathers commented on GitHub (Jan 16, 2020): v0.4x is a complete rewrite of the UI component using React 16, and thus has a completely new rendering mechanism that is likely more performant than backbone. No hard benchmarking has been done, so feel free to create any new issues around performance.

kerem referenced this issue

2026-02-26 05:31:44 +03:00

[PR #122] [MERGED] Fixes harvester durability issues, addresses #70, #85, #114, #120 #248

kerem referenced this issue

2026-02-26 05:31:44 +03:00

[PR #127] [CLOSED] Better tests, fixes and documentation #249