Hi all, Discord engineer here! If anyone has any questions about the post or our experience using React/React Native the team would be happy to answer them!
In your defense, it's a cancer that all "modern" apps done in javascript suffer from, but still, why?
Edit: for those who don't want to click, it's a screnshot of the os x activity monitor showing the worst memory consumption, in order: Discord Helper 1.98 Gb, kernel_task 1.67 Gb, Skype Helper 1.58 Gb, Slack 1.20 Gb :)
Modern RAM doesn't work the way people who complain about Slack/et al think it does. The operating system will cull it from other places when it needs it; even a native Cocoa app will not dump memory you're done with until the system decides it needs it for something else, because on the off-chance your app ends up needing it again, it's already allocated. "purge" exists for a reason.
It's like when you pull up a StackOverflow answer for "how can I judge how much memory usage my process has?", and the top voted answer is some bash script to determine peak ps, when every other answer tries to explain that that's only one measure of memory and isn't even totally accurate.
Furthermore, that nice feature of most modern apps where you're scrolling up rapidly and an image is nice and ready to present? Images are big, especially when we all use retina displays. They take up memory. There was a blog post that went on HN a few months ago but didn't seem to make the front page, wherein the author determined that forcing Electron to dump image cache junk lowers the memory usage substantially.
Could Electron & co do better? For sure. Loading an entire browser for a UI does kind of suck. But stop acting like all the stuff that the browser does for you _for free_ is or should be zero-cost.
End rant, I guess.
If i don't restart the machine for a year, is the pretty chat app going to keep in ram, uncompressed, all the cat pictures that people posted in the last 12 months then? Do you think that's sane?
That is just not how memory works anymore, at least not how the OS reports it to you.
> The system was responding slowly when I made that screenshot because it started using swap.
How did you determine this? If you're looking at swap usage in activity monitor, this is also not an accurate metric. I'm sitting here with 14GB used, 18GB free and 2GB of swap usage. Using swap does _not_ mean you are out of ram, it just doesn't work like that.
Is the memory pressure graph in activity monitor yellow or red? If not, which is likely the case, you don't have memory issues. You don't need more memory and it doesn't matter how much memory your applications are using.
...until I hit 8 gb of ram (the amount installed on my machine). The second that happens, the entire OS grinds to a halt. It starts with 5-10 seconds to change focus, and can go as high as 5 minutes if I don't do something about it. My best option for dealing with it is usually opening a new console (Ctrl-Alt-F3) and killing Android studio or the gradle daemon (the most common culprits). If I'm able and patient enough to open system monitor at this point, I can see that my swap usage has increased dramatically.
Again, I can't speak to "how memory works", but I am absolutely the expert on how my computer performs, as described above.
I'm assuming you mean 8GB of ram 'used', by some metric of 'used'. What tends to confuse the hell out of people is what 'used' means. It varies by how it's measured, what OS you are using and how that OS is configured. I haven't a clue how Fedora 27 is configured nor how you are determining 'used' RAM, so my comment may well not apply to your use case.
And frankly, it seems to me like the issue is the OS being unoptimized or apps being leaky on it, because my Windows 7 machine with worse specs almost never has such issues, under any kind of similar load (and exactly the same apps).
I don't know how your OS X works, but mine tends to not go into swap before running out of ram. It does not come out of swap when ram is freed indeed, but when you freshly boot it it will stay at swap used: 0 bytes until someone posts too many cat pictures in Slack or Discord.
Or until i forget how many VMs I opened, but that's work and actually useful.
Edit: I can't reply to your reply because HN doesn't like so many indents. I also don't want to continue a flame war about observed behaviour vs the theory of shared libraries and memory mapped files etc so I'll stop here.
If your RAM is full, there is a probability that something will need to be read from disk. If your RAM is empty, there is a certainty that something will need to be read from disk or from the network. A probability of a slow operation is preferable to the certainty of a slow operation. Something in RAM is preferable to nothing in RAM.
The pretty chat app will not keep all of your cat pictures in RAM indefinitely, because the OS won't let it. If something else needs that RAM, then the cat pictures will be paged to disk. The OS is incredibly good at figuring out what belongs in RAM and what belongs on disk at any given moment.
(all speeds are read time) RAM speed: 35 GB/s Disk speed: 3.2 GB/s Network speed: 0.87 GB/s
While you aren't wrong, I have no problem loading cat pictures at network speed instead of ram speed.
I think the real issue here is network consumption is expensive. It's better if you store all your cat pictures for as long as possible. People would complain in discord generated gigabits of temporary disk files, but RAM usage can always be freed if the OS demands it.
You probably run a machine with above average ram and ship apps with below average performance for lack of this understanding.
RAM that's reported as "free" by OS X's activity monitor/windows' task manager is used for disk caching.
RAM reported as in use by an application is in use by that application. It could be using some sort of internal cache, but it does not give that memory up to other apps under memory pressure except by the OS swapping it out which gets very slow.
Its not clear to me how it would apply to other memory how does the os communicate to Firefox that it needs to clear out some memory for Chrome save by moving less used pages to swap with the probable high cost, of moving it back later. Further while some intelligence may be exercised insofar as which pages to swap it won't be made with the benefit of the app deciding which chunks of data to keep closer at hand.
Modern memory works the same way it always has and the best performance has always been maintained by staying within the boundaries of available ram and not needing to swap much.
When most computers have no more than 8gb of ram and consumer machines are likely to have 4 its kind of silly for a chat app to use 1-2 sillier yet to claim that the os will fix the matter.
The only reliable way to learn the memory consumption of a process is to somehow make sure other processes don't allocate/deallocate memory, kill the process in question and watch the difference in global memory consumption.
For anyone interested to repeat it fast, run this in powershell:
Get-Process | Format-Table WorkingSet > c:\data.txt
Import contents in excel and sum all cells.
I've seen startup latency much slower than that on my iPhone SE. In the best case, the application takes about six seconds to cold boot when I tap on a notification. Sometimes it's closer to fifteen or twenty seconds if the app sits on the "connecting" screen for a while. It's difficult to understate how much slower the app feels than everything else on my phone.
Meanwhile, we keep working towards to improving our user experience on all the devices especially the lower-end ones (I personally use iPhone 6 as my go-to test device). For instance, we will add caching very soon to shorten the interaction waiting. Hopefully you will enjoy more using Discord on your SE then :)
If we had some magical way to make the dev treadmill run slower than the user treadmill, we'd see better architectures in many cases. In that alternate world it would be easy to precompile the javascript and load 20 times faster.
iOS users tend to run newer devices generally which might lead some devs to feel that this extra optimization isn’t worth the time it takes, but I disagree because it doesn’t benefit only users with older devices – it’ll make your app run better on newer devices too and make it that much more unlikely that your app gets killed or causes the OS to kill other apps in multitasking scenarios (iOS kills resource hogs much more readily). In short, everybody benefits.
With this same thought process, I plan to pick up one of the 120hz iPad Pro models to test on soon. It’s one of the most powerful iOS devices available, but driving 120FPS isn’t easy and given how many apps fail to hit the target of 60FPS on similar hardware I’d bet that a huge number, perhaps even most, don’t come anywhere close to running at 120FPS even with the extra horsepower.
Thanks for all of your work.
And thank you for helping make Rust awesome.
* Have you evaluated cross-platform "native-ish" alternatives? (Nativescript, Flutter, etc.)
* What does the "lack of 64-bit support" mean for Android?
* This can be worked around by deferring work when doing transitions/animations based on user interaction but at the time we only had a single Android Engineer (myself) and I felt it would be an overly large hurdle to cross. The team is however still interested in trying again some point in the future now that we have more time for it.
* The minimum version we support is API level 16 which is quite old and we may eventually bump that to 17.
* We have not evaluated any native-ish alternatives mostly due to bandwidth but also because the goal is to re-use our stores/business logic from the desktop/ios clients so we can move faster.
* On 64-bit support https://github.com/facebook/react-native/issues/2814 it ca be worked around without much consequence but is a consideration as ones application grows in complexity and dependencies.
I believe it's something we may eventually take on - just not currently planned - there are a lot of ways we could make the nitro experience better.
Any other insights would be great, as I'm planning to start converting my web app to RN in the next months and didn't know Android would be a problem.
When we originally got it running on Android (without the chat view since that component is native in the iOS app) we found that it performed quite poorly due to most of our pages being heavy on data and UI - as well as being very reactive (a typical discord server might have hundreds of permissions, messages and users all changing/updating in real time). React Native is single threaded and while iPhone’s have great single threaded performance, Android phones are more reliant on multiple cores and RN as I understand it mostly can’t take advantage of that.
On higher end Android phones the performance was actually fairly acceptable out of the box, but our user base has a lot of gamers who are running very old Android phones from many years ago - and in those situations the lag was unacceptable. For iOS, most users tend to only last one or two hardware generations behind.
Additionally, at the time React Native for Android had just been released and there were a whole host of other issues at the time - bugs and lack of Android specific components like the Navigator (which have since mostly been ironed out).
Today I think it is possible to build a fast React Native Android application and I would recommend someone starting from scratch do so :). However now the challenge is that we have an existing Native Android app so our users already have a baseline expectation of feature parity and performance. If we switch over we must meet or exceed that bar.
The only thing left that really bugs me is the fact that you can't paste images from the clipboard into the message field. It's made me change my entire workflow, from copying images to saving them.
Sorry to use this as a soapbox for my pet issue, but I saw the opportunity :P
So stay tuned!
Thanks for the kind words, the team really appreciates it.
One question that popped up in my while reading the article was would you consider doing the android app in react native if you had to start now ? Or do you still feel it lacks the coherency it has with iOS.
While the performance footprint is mostly the same - the ecosystem and feature set around it has improved a ton to the point where I believe you could get it 90% there very quickly.
One of my friends has a small startup and they went full React Native as a team of two and they describe the Android side as "free" as in they really just focus on iOS and it 90% of the time it also works fine on Android (they care less about older devices at the moment so they don't spend time optimizing for those).
Android inherently will always have challenges due to the vast number of devices and hardware/performance problems but going native isn't a silver bullet either and doesn't shield you from the challenges entirely - it's just a familiar form of pain ;P
I've been using Discord's OAuth and that's been nice, but I what I'd really like is to display that status on my site.
Is this what's expected from the app?
I'm not an expect on voice but iirc we do use a different codec than Skype so the audio is not going to be identical however, we have advanced settings in the `Voice and Video` section of the settings that allows you to enable/disable things like Echo Cancellation and Voice Suppression that could be the cause of the feedback.