Yes, there are definitely optimizations that can be made here.
Keep in mind that this plugin is effectively a different front-end for the same topic-based pm system that Discourse has. I’m not surprised that it may not perform well if you are carrying on multiple conversations at once. This is not a separate pm system.
The benefit of using the same PM system as Discourse is that it allows you to switch between normal Discourse PMs and quick messages. It is not a separate chat system. If you’re after a chat system try Babble.
Every time you make a message it sends it to the server like a normal post, going through all the same processes a normal post goes through, but with a significantly simpler UI.
But it has a cost…
So, the question is where to start when optimizing this.
From my relatively un-trained perspective, here is how I think of the possibilities:
- slimming down the client. Easier. I can do this and will do some.
- slimming down the server. Harder. Also something I can attempt, but the result won’t be amazing.
- batching on the client (probably not wise)
- batching on the server (probably the best place to tackle the problem, but someone more familiar with ruby and rails should do this)
The next question is how we go about executing on one of these approaches. As mentioned, I can probably get some performance gains, but I’m hardly the most technically savvy person around here.
It depends how much it matters to you. Optimizing the performance of quickly posting PMs is not a simple problem, as you’re dealing with functionality that is core to Discourse itself.
Someone like @gdpelican or @joebuhlig could probably get significant performance improvements for a fee.