Android coding is a constant reminder of how much performance relies on you knowing the exact inner workings of your environment:
Today's case: `array.toList()` is 4x(!!) slower than `listOf(array)` to return exactly the same thing.
But don't worry, there is also `array.asList()`, which is just 2x slower and `Arrays.asList` which is slighly faster than `listOf`.
This is not confusing at all.
Huh?
Classic.
Good habit is to define your own abstraction in some "commons" module and always use it, and never rely directly on other libs.
At least progressively aim to that standard.
Yep, I am redesigning our whole caching system to avoid future me using the wrong method. 🫤
Talking about cache: how can i force reload badges? I am playing around with them, but after changing the badge image, i still see the old one. Is it save to clear the apps cache, or will i then have to re-enter my nsec?
And then they deprecate one method that was ideal or improve upon another. Or you find some weird edge case in which one of them turns out to be slower with lists > n.
It's always so many trade-offs and decisions to make on whether to improve X, fix deprecation Y now or make new feature Z..
That sounds like some sort of word puzzle that’s supposed to have a “oh, of course! Hahaha” answer.
😂 Terrible...
I heard in some ECS/data-driven-design lessons for game design that it’s generally faster to have structs of arrays than arrays of structs. Perhaps it’s the same thing here?
Pro tip: Use Haskell and compile to machine code.
Beware this requires skills.
Skills not found.
All languages are like this. foreach() in PHP can be an order of magnitude slower than a standard for loop. C/C++ do all kinds of wacky things. The problem is that there is no money in language design. Most languages are either built by unpaid volunteers or companies that just see it as a cost center.
You want to here something really depressing? It's almost always quicker and more cost effective to throw hardware at performance problems than spend valuable dev time fixing them.
This is why open source software can be significantly better than commercial software. It is generally built by people who don't mind spending the extra time to do things right. The down side is that it takes longer to do things right. Software is always about tradeoffs. The more you understand the systems you have to work with, the better you will be at making the right choices.
is it possible to
If
press zap button
Then
field to type in X ammount of sats.
In my opinion, it would be more efficient to have single tap zap a predefined default amount (since I almost always do the default amount and currently have to tap the icon, then an amount for two clicks instead of one), and have long press/double tap either be combined, or break the wallet connect and default zap amount settings off into a zap section under the app setting menu.
But I'm operating under the assumption that most people also zap the same default amount most of the time. I would be surprised if most people type a custom amount every time they zap, but I don't know for sure.
I use the zap button like the heart icon on X, for example, 99% of the time. It's essentially a 'like' button for me.
Zap settings for the default zap button behavior would solve this for everyone, but it would be a lot more logic I think.
wen build rust for JVM
Do you think they leave them all in for compatibility reasons? I can't see why you'd want to do something in a worse way, unless there are other tradeoffs I'm missing.
?cid=6c09b952l3le4wnj8a79n2ljkjplxlgqghminifofvnd3vbp&ep=v1_internal_gif_by_id&rid=giphy.gif&ct=g
