this post was submitted on 13 Jun 2024
29 points (100.0% liked)
Learn Programming
1658 readers
1 users here now
Posting Etiquette
-
Ask the main part of your question in the title. This should be concise but informative.
-
Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.
-
Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.
-
Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Map, Filter, Reduce Those are the big three for data. More important than those however is mindset and patience with oneself. Writing code that works is the first and most impressive step. Optimizations are fun to think about but unless your computations are sluggish and repeat a lot of unnecessary steps they are rarely a priority.
Build something and shelf it. Trust me, in but a few months you will look back in bewilderment and realize how much you've grown.
In other words, the kind of optimizing that's worth it is choosing a better algorithm to reduce its big-O complexity class.
I was thinking about caches and evaluating what calculations I want to do.
I fixed a project for someone simulating a machine. That took them almost 9 minutes. Simply replacing the part where they initialised a solver and used it to find a zeropoint of a quadratic function with a call to that initialiser got it down to a minute.
You should have seen their faces when we put the quadratic formula in and it took 28 seconds.
The mental model I have about performance is that the higher abstraction usually beats the lower level abstraction.
So in that sense, a well architected software with proper caching, multithreading where it matters etc. will beat badly architected software (ex: one that brute forces everything). Then, that being equal, good algorithms and solutions beat bad ones. Only then faster runtimes make more of a difference, and at the bottom things like more efficient processor architectures, more efficient compiler etc. beat slower ones.
A good example is Lemmy itself, which as far as I know was made in Rust to be super fast, but then at the beginning was being DDOSed quite easily because of the way the database was designed and lots of queries were very slow. Once they fixed that, Lemmy became actually usable.