Skip to content

Conversation

@stigger
Copy link
Contributor

@stigger stigger commented Jul 8, 2017

The current version does not work very well with large (thousands of messages) histories. The single fact that ChatSecure loads all messages at once affects many areas:

  • initial opening;
  • loading new messages due to a push notification;
  • overall responsiveness (scrolling, typing).

Without going into details, the issue is that too much data is being processed to often without any reason to do so (and often on the UI thread).

There are two main changes in this pull request:

  • instead of loading the entire history, load only the last 50 messages, and load the rest on demand;
  • handle message loading more efficiently by caching and offloading to background threads the most heavy calculations.

Closes at least #360 & #470, maybe some others.

@chrisballinger
Copy link
Member

Awesome thank you! I'm away at the moment but I'll plan to review this next week

@stigger stigger mentioned this pull request Jul 22, 2017
@chrisballinger
Copy link
Member

I really like what you've done here! Works really well! Apologies that it took me so long to review, I was away the last couple of weeks, but am now back working full time.

@chrisballinger chrisballinger merged commit f7dc0f9 into ChatSecure:master Jul 26, 2017
@stigger
Copy link
Contributor Author

stigger commented Jul 27, 2017

Thanks for merging! I'd really like to see a TestFlight build with these changes: ChatSecure became practically unusable for me because of a large history.

@stigger stigger deleted the chatview-performance branch July 27, 2017 00:02
@chrisballinger
Copy link
Member

Definitely. I found some issues w/ the PR after the merge, so I'm fixing that up.

The optimization to pre-calclulate the bubble size makes the Xcode 9 UI thread checker complain, so I've removed that part for now.

@stigger
Copy link
Contributor Author

stigger commented Jul 27, 2017

I'd say that it's safe to ignore the UI thread checker. Accessing UIKit on background threads is not inherently a bad thing. In this case we're not modifying anything, only accessing already existing structures.

In the worst case (if the JSQMessagesCollectionViewFlowLayout changes on the UI thread while we're calculating) we might end up with incorrect bubble size, but I don't see how that's possible. Still, I'll try to submit a PR to JSQMessagesViewController that allows to implement this without accessing UIKit on background..

@chrisballinger
Copy link
Member

Too bad JSQ was abruptly shut down and no community fork has emerged... :( https://www.jessesquires.com/blog/officially-deprecating-jsqmessagesviewcontroller/

Yeah I don't disagree with you about the verbosity of the main thread checker, but I err on the side of caution because I can't see the internals of UIKit. Even without that block though, your PR still speeds things up dramatically!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants