msglist: Mark-as-read button takes a long time (batch-processing already-read messages) #377
Labels
a-api
Implementing specific parts of the Zulip server API
a-msglist
The message-list screen, except what's label:a-content
performance
Smooth and responsive UI; fixing jank, stutters, and lag
Milestone
In
#test here
on CZO, if I let there be just one unread message, then I tap the recently added "Mark 1 message as read" button (#364), it regularly takes 4 to 5 seconds for that single message to get marked as read.It looks like the server is doing some work on (maybe just accessing) a large number of messages that are already read. Here is some console output, where you'll see response data from the mark-as-read requests, alternating with the corresponding mark-as-read events:
(It's odd there to see mark-as-read events where
all
isfalse
andmessages
is empty. I don't think that case is acknowledged in the API doc.)Note that in the request response,
first_processed_id
increases over lots of message IDs that are already read. This seems like work that could be avoided. I found that I can cut out all the unnecessary work by addingis: unread
to the requested narrow, making the request take a short time, as expected:But this might be a case where the server shouldn't need the client to tell it to make that optimization, and it should just go ahead and make it.
(Same with the all-messages case; here's more of the code in
main
surrounding that diff, with a relevant comment:.)
The text was updated successfully, but these errors were encountered: