Rubicon/tutu
1
0
Fork 0
Code Issues 19 Pull requests Projects Activity Actions

Tutu uses too much memory #33

New issue
Closed
opened 2024-10-24 07:33:08 +00:00 by Rubicon · 3 comments
Rubicon commented 2024-10-24 07:33:08 +00:00
Owner
Copy link

Reproduction:

  • iPhone 12, iOS 18, installed as a standalone.
  • In the "Timelines" page, one of the timeline, like the "Home".
  • Scroll to bottom, click "load more" or use the "prefetch toots" option.
  • The app randomly crashes and restarts.

My guess is the app uses too much memory.

Reproduction: - iPhone 12, iOS 18, installed as a standalone. - In the "Timelines" page, one of the timeline, like the "Home". - Scroll to bottom, click "load more" or use the "prefetch toots" option. - The app randomly crashes and restarts. My guess is the app uses too much memory.
Rubicon added the
bug
user-agent/webkit
performance
 labels 2024-10-24 07:33:08 +00:00
Rubicon changed title from PWA crashes after "load more" multiple times on timelines page. to Tutu uses too much memory 2024-10-29 07:32:30 +00:00
Rubicon removed the
user-agent/webkit
 label 2024-10-29 07:32:47 +00:00
Rubicon commented 2024-10-29 07:35:24 +00:00
Author
Owner
Copy link

Observed on Firefox(Linux) in development mode: in the timelines uses 300-400MB, in reload or HMR can bump to 600MB

Observed on Firefox(Linux) in development mode: in the timelines uses 300-400MB, in reload or HMR can bump to 600MB
Rubicon commented 2024-10-29 07:38:28 +00:00
Author
Owner
Copy link

Observed on Firefox(Linux) in development mode: in the timelines uses 300-400MB, in reload or HMR can bump to 600MB

This happens after we use ResizeObserver to calculate layout in MediaAttachmentGrid. Previously the number is usually 250-400MB.

I don’t know if we need to switch to another layout for this.

> Observed on Firefox(Linux) in development mode: in the timelines uses 300-400MB, in reload or HMR can bump to 600MB This happens after we use ResizeObserver to calculate layout in `MediaAttachmentGrid`. Previously the number is usually 250-400MB. I don’t know if we need to switch to another layout for this.
Rubicon commented 2024-11-01 05:31:39 +00:00
Author
Owner
Copy link

I think this problem is partially solved by using css containment.

I think this problem is partially solved by using css containment.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
stacky
v1.0.8
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3
v1.0.2
v1.0.1
v1.0.0
Labels
Clear labels   
bug

Something is not working

  
duplicate

This issue or pull request already exists

Archived

  
feature
accepted
New feature that is accepted and will be implemented

  
feature
proposal
This is a proposal of a new feature

  
help wanted

Need some help

  
invalid

Something is wrong

Archived

  
performance

This issue is about performance

  
question

More information is needed

  
user-agent/chromium

Chromium-based platform. Chromium/Chrome/Chrome on Android

  
user-agent/webkit

This issue is related to Safari or other WebKit-based browsers

  
wontfix

This won't be fixed

Archived

No labels
bug
duplicate
feature
accepted
feature
proposal
help wanted
invalid
performance
question
user-agent/chromium
user-agent/webkit
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Rubicon/tutu#33
No description provided.
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?