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
Experience is the best teacher. Keep writing code, revisit old code and rewrite it.
Also, is worth knowing when not to optimise. Code you can read is code you can maintain, and some optimisations are not as readable.
Learn how to use a profiler. Its a bit of an artform, but learning to interpret the results will help you find slow code sections. It'll also help you determine if your optimisations are actually worthwhile. Measure first, optimise second.
Also, is worth knowing when not to optimise. Code you can read is code you can maintain, and some optimisations are not as readable.
This is one of my biggest pet peeves. So many people want to equate the number of lines as a sign of how well it's programmed. But all they really do is chain a bunch of stuff together that makes it harder to debug.
Annoys me as well. Blind optimisation is just busy work, you need to know what your optimising for.
And less lines != better performance.
“Any improvements made anywhere besides the bottleneck are an illusion” (Gene Kim)
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.
but unless your computations are sluggish and repeat a lot of unnecessary steps
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.
The functions you've called out are higher order functions regularly associated with the functional programming paradigm. "In the first place" for a lot of people would be a functional programming course at a university.
For your specific case, rust (like a few other languages) implements these through iterator programming. There's a section in the rust book that might help.
Apart from academia you learn from experience, including a healthy amount of reading other people's code, just like you did to find out about these functions in the first place!
Also, with Rust, if you're optimizing for performance and not legibility, it's actually pretty important to not prematurely optimize. Its type system gives the compiler a lot of information to work with, and it does a really good job finding places where code can be optimized.
What might make sense in some languages, such as trying to cache small strings instead of recomputing them, can actually hurt performance by preventing the compiler from using certain optimizations.
This is probably going to get downvoted into oblivion but: try writing some Haskell for a while. Learn You A Haskell is a good place to do it, just bail out when you get to monads.
When I was taught programming at university, we did one assignment in Java, then the next one was the exact same assignment but in Haskell. The idea was not to bias us towards imperative vs functional programming. I don't think it worked -- I would guess almost everyone preferred Java -- but over my career I've learned how much Haskell has offered me for writing imperative code for my day job. I think you will get what you are looking for by trying some Haskell for a while.
just bail out when you get to monads.
Isn't writing Haskell nearly equivalent to writing monads? How could they start without using monads?
What you're asking about (how to learn clever techniques to e.g. turn your naive O(n^2^) algorithm into an O(n log n) one) is the kind of stuff taught in an algorithms / theory course as part of a CS degree. Here are some of the first search results for open content courses I found that look like they cover the right topics:
https://ocw.mit.edu/courses/18-404j-theory-of-computation-fall-2020/pages/syllabus/
http://openclassroom.stanford.edu/MainFolder/CoursePage.php?course=IntroToAlgorithms
You also might want to consider a combinatorics / discrete math course.
In case others want to get into 18.404j, but don't have the prerequisite knowledge, I made a pretty complete graph of all available MIT courses (at least until 2023) and linked them as a left-to-right dependency graph:
https://thaumatorium.com/articles/mit-courses/mit.drawio.svg
Just search for 18.404j - it's an SVG, so search works.
I recently wrote something that really stretched my understanding of lexical scoping and functional programming. In the end, I think the only way is RTFM and just keep coding.
I learned that type of stuff in college, so I can't personally recommend any online sources. However, I can tell you that what you're looking for falls under "Data Structures and Algorithms". IIRC my degree required 3 classes with that name. Lots of sorting algorithms in that field since they make great case studies.
You learn the various data structures and algorithms available, their strengths and weaknesses, how they work, when to use them, etc...
You also learn how to measure performance, like Big-O notation, the bane of many a CS student's existence.
Code more. Run profilers. Try different solutions.
When I started learning programming, I was like "tf is a map function?" and I always forgot about it. Then I tried the functional programming language Erlang and understood all these functions very well. But there is a downside, now most for-loops in C++ look terrible to me :)
Some of this is probably just getting to know your tools. Learn the language, look at others' code and interrogate what they did and why. The higher-order functions (scary-sounding term, but they're not actually scary) you mentioned are useful, go learn them and use them.
Some of it might also be (I haven't seen your code) getting a better understanding of the problem you're trying to solve. Figure out what all the separate pieces you need are, and then break those pieces into their pieces and so on, until you've got simple, self-contained chunks of functionality that you can give simple names to. Some of those might be functions, or you may find that they're simple enough that they don't need to be. Refactor and think about how to make the problem simpler. I think a lot of it is just staring at your work and dreaming of ways the make it simpler and easier to read.
If you really want to optimize for performance, that can come later once you really have a feel for it.
