jb55's avatar
jb55 _@jb55.com 6 months ago
Nostr Android Performance Showdown Damus vs. Amethyst vs. Primal Which app is the fastest on a $100 android phone?

Replies (104)

jb55's avatar
jb55 _@jb55.com 6 months ago
also damus android performance doesn't really change depending on whats being loaded. its completely independent from ui. once the data comes off the nostrdb subscription it is fully parsed and ready for rendering.
Improving performance, local-first, network-connection efficiency, etc. is not just about being a microsecond faster; it's also about expanding the market into poorer or less well-connected communities. There is still so much that we could eek out...
jb55's avatar
jb55 _@jb55.com 6 months ago
I don’t know, i just built a client from the ground up based on all the lessons i learned and mistakes i made on the iOS side.
True. But If that is the whole pitch, then it's going to fail as well. If an app can solve for 90% of users and then your app comes to solve the other 10%, the 10% app still only own 10% of the maket. Because in order to make things really fast for low end devices, you have to reduce the feature set. And that will be a big no no for the other 90%. Performance is always a function of feature set first. Then other things can help, like local cache and so on. The great thing of Nostr, and AI nostr in particular, is that we will be able to ship apps with the best matching feature set for each device capability. That's our future.
jb55's avatar
jb55 _@jb55.com 6 months ago
Still very early days. This might be the first complex egui mobile app. Lots of warts to patch over in terms of system integrations
Sure. I also see those in virtually every Nostr code base and my own code. But my users don't care if I have a perfect Boolean algebra or the most efficient workflows. They care about doing the thing they want to do in the best way possible. That's what I am focused on. And I attribute most of Amethyst's success to focusing on them, not on the perfect code.
Did you try Yana and Voyage? Those are much faster than Amethyst. I didn't say I am unaware of the performance issues we have, but for some devices, people just won't be able to run Amethyst. It's not designed for them. In order to make some stuff work in some phones, I need to make things worse for everybody else. For instance, loading could be much faster on Amethyst, but I had to reduce the speed to minimize battery drain. So, it usually takes a second between the event coming to the phone and a screen update, instead of updating the screen immediately multiple times a second as things come. In this case, I specifically chose a slower approach to expand the number of devices we can run on. And that was terrible for some users. But most people didn't notice at all. But that has a limit. After some point each percentage point in coverage might make things more visible to the rest of users. I am constantly searching for things that don't affect the other users. The easiest one is to just remove all of our feeds and features. For instance, if I don't load NIP-17 DMs, then the app is already almost 5x the loading performance simply because receiving DMs and building the user list for of the latest chats is quite a task (decrypting every message).
I've tried Voyage, but it sacrifices too many features to compete with Amethyst. I bet you could tie more performance improvements into the low-data mode and let people opt-in to it. I don't use the DMs, for instance. The once per day, that I check them, I can manually trigger the fetch. I actually bought a new phone, just to use Amethyst, and then I got crushed by spotty mobile Internet. Tighter integration with Citrine and automatic network diagnosis could potentially make moving in and out of the connections seamless.
We tested... People really didn't like the fast that they had to stop scrolling to see the reply number increase. People thought they didn't receive any new replies and missed stuff. So, we rolled that back :(
Agree. We need a better integration with Citrine. But citrine also needs to be faster. Even strfry running on the phone is slower than pinging a server if citrine/strfry needs to go to the disk to get something... Servers generally keep everything in memory.. so they reply super fast. We will see. Now with outbox I am also doing a broader filter redesign to minimize asking the same stuff to different relays. The new issue will be that many people keep 20+ relays in their list and that means that the app needs to search in all of them to not miss things.
Ah, but you're thinking of performance as merely being speed. There are different aspects, like reduced bandwidth usage, computation minimization, constancy, etc. What Citrine can do is smooth out fluctuations in the connection strength. If you were background-downloading into Citrine, while in a fast connection, and then pulling from it, when the connection faltered, then the user wouldn't even notice the fluctuation. He'd just scroll up and see the next post. Scroll up again, see another next post...
It is. And everyone dances differently. I see in the vid that Damus hasn’t loaded other stuff while Will is scrolling. So looks like they made this trade off … 👀
Yeap, but citrine is quite slow. If you add citrine to your local relay list, force close amethyst, go offline and open the app, you will see how slow it gets. So, most of the time we receive the event from servers faster than this local relay. StrFry Android is faster than citrine, but you will need to learn how to install in the command line.
jb55's avatar
jb55 _@jb55.com 6 months ago
? notedeck will load unknown ids in a debounced manner. no outbox yet though.
It was friggin brilliant to put a relay on Android. I don't doubt that it can be made even moar brilliant. Even a slow relay solves for concrete problems. I read books and magazines directly from Citrine, even without an Internet connection.
jb55's avatar
jb55 _@jb55.com 6 months ago
it would be slow if it was in a relay app. you pay the cost of sending it over a socket, parsing, etc. with nostrdb its a single btree lookup into memory with a cache aligned struct pointer
Split it in two and make the relay available and the cache as a separate lib. It would be similar to what I and the web stacks are doing these days.
it makes me sad because back in 2018 i was writing code on android cointainers but that whole thing evaporated. i was homeless and had nothing but a sony experia and it let me do that back then but they basically killed the whole genre. good luck finding a device that can run cyanogenmod now. in 2016 there was many. the scumbags basically shut all that down because of course they only want to serve their masters in langley and whatever the place is that mi6 is centered. b something
Brobro you cleared all the other apps wheb you loaded up damus you think you slick!!!! Bro hahahaha I'm jk you gotta sauce it up i respect it 100% I'm excited to use damus !
dluvian's avatar
dluvian 6 months ago
Up until 2 years ago I was using a shitty phone from 2017 and Amethyst ran better on it than what you showed. At that point the big downside of Amethyst was not performance but cluttered UI and high data usage. I hope this new client doesn't eat up all my data.
The profile screen is the worst screen in amethyst. Even after leaving the profile screen it makes the app unusable after a while and I have to force close the app and clear cache His video would be much better if scrolling the global feed
I think data usage would decrease a lot if we didn't open the same subscriptions all over again when scrolling the same posts. It would be fine something like load only after some minutes or load again the data if the user opened the thread view But I haven't tested this so I have no data to know if it would help with data usage
jb55's avatar
jb55 _@jb55.com 6 months ago
we do since optimization on every subscription, we’ll do negentropy soon for everything
the axiom's avatar
the axiom 6 months ago
this is very important to show as developers only ever have the best devices and never test on the cheaper ones
dankswoops's avatar
dankswoops 6 months ago
Nice work brancing to android. Also to be fair, closing a process on the phone improves performance and this doesn't give a true bench mark since your app ran alone where there's didn't. I'm independent on favoritism.
n's avatar
n 6 months ago
いいね👍
O Will, criador do Damus, testou a performance do Amethyst, do Primal e do Damus (versão para android) para um celular android básico e obteve o maior desempenho no Damus. O celular em questão foi o Samsung Galaxy A14, que custa 100 dólares americanos, mas é possível que se obtenha resultados diferentes para outros celulares android.
jb55's avatar jb55
Nostr Android Performance Showdown Damus vs. Amethyst vs. Primal Which app is the fastest on a $100 android phone?
View quoted note →
I might not bother with trying it given that @jb55 has muted me for no reason after I zapped him 50k sats in the past for his work on shit I can't even use yet as a non Apple user
I'm curious what coracle's android app looks like. People say web is slow (and I get why), but I've spent a lot of time getting out of my own way so stuff is smooth. It would be interesting if a web app can out perform a native app.
npub1wamvxt2tr50ghu4fdw47ksadnt0p277nv0vfhplmv0n0z3243zyq26u3l2 It seems like some people don't like it when we support what they do. That's what this project is going through. It's doing everything it can to reach more people but it seems like people are turning it off. Check this out and tell me what you think. It's about sharing hope, smiles, and love to those in need. @Hope With ₿itcoin
You just made me realize how awful YakiHonne is performance wise. Still in the right direction z though, seeing potential.
================================= #2 🔥 Community Highlights ================================= 1. #Nostr still has a chance to challenge X View quoted note → 2. The social protocol that uplifts the community with GM View quoted note → 3. Movies on Nostr soon View quoted note → 4. A Popular pleb is gonna replace his laptop for a powerful one View quoted note → 5. An amazing way to get quick access to your favorite nostr profile View quoted note → 6. The @primal onboarding progress View quoted note → 7. A new pleb is gonna learn Nostr View quoted note → 8. An impressive poem on Nostr View quoted note → 9. The complains by plebs about @ODELL View quoted note → 10. A reward for the attendees of @BTC Prague View quoted note → 11. The fastest android client check on Nostr View quoted note → 12. A great decision from a great Dad View quoted note → 13. Another new onboarding on Nostr View quoted note → #community_nostr_recap
jb55's avatar
jb55 _@jb55.com 6 months ago
There are many many reasons, i have engineered the rust and C code to be fast and cache efficient. kotlin/jvm is a completely different runtime environment, and a naive implementation of a nostr client will be slow. Lots of careful engineering is the gist of it. I approached it like i would a video game with a very tight frame budget.
You're crazy, I often wonder how you learned all this low level stuff. Thanks for you for the well detailed response.