addNewStatuses efficiency #1152

Open
opened 2022-03-25 01:14:32 +00:00 by tusooa · 1 comment
Owner

https://git.pleroma.social/pleroma/pleroma-fe/-/blob/develop/src/modules/statuses.js#L156

this function calls sortTimeline(timelineObject) which contains a simple sort. I am skeptical about the efficiency of this. could we maybe benchmark this?

see also https://stackoverflow.com/questions/1344500/efficient-way-to-insert-a-number-into-a-sorted-array-of-numbers

https://git.pleroma.social/pleroma/pleroma-fe/-/blob/develop/src/modules/statuses.js#L156 this function calls `sortTimeline(timelineObject)` which contains a simple sort. I am skeptical about the efficiency of this. could we maybe benchmark this? see also https://stackoverflow.com/questions/1344500/efficient-way-to-insert-a-number-into-a-sorted-array-of-numbers
Owner

First of all, i think the data being sorted is already mostly sorted most of the time it's just to correct any errors, i.e. when you make your post it's automatically added on top but that might be incorrect if some other posts arrived at same time or when old request takes longer to arrive than new one. So most of the time efficiency should be about O(N) even with bubble sort (which is what browsers use), where N is within few hundreds normally and within 1-2 thousands at worst (when you leave pleromafe running over a weekend unattended). It should be still relatively fast to bubble-sort 2000 mostly-sorted items even on a Pentium 4 machine.

Seconf of all, if you really want to fix inefficiencies you should instead look at components rendering - I benchmarked some similar issue (when you have 9000+ emoji on your instance) that I thought was inefficient from algorithmic perspective but that inefficiency was tiny (less than 1ms) compared to component rendering time (50ms multiplied)

First of all, i think the data being sorted is already mostly sorted most of the time it's just to correct any errors, i.e. when you make your post it's automatically added on top but that might be incorrect if some other posts arrived at same time or when old request takes longer to arrive than new one. So most of the time efficiency should be about O(N) even with bubble sort (which is what browsers use), where N is within few hundreds normally and within 1-2 thousands at worst (when you leave pleromafe running over a weekend unattended). It should be still relatively fast to bubble-sort 2000 mostly-sorted items even on a Pentium 4 machine. Seconf of all, if you really want to fix inefficiencies you should instead look at components rendering - I benchmarked some similar issue (when you have 9000+ emoji on your instance) that I thought was inefficient from algorithmic perspective but that inefficiency was tiny (less than 1ms) compared to component rendering time (50ms multiplied)
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
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
pleroma/pleroma-fe#1152
No description provided.