devc1 wrote:
But whatever I had never tried to understand what is this hashmap. I just create linked lists
This proves my point. You are looking for performance at the micro level, which is the last place performance should be found at. You should first think about basic algorithms. A hashmap will beat a linked list in lookup intensive operations
always. Now is a hashmap always faster? No. It's about using the simplest thing that will give you the best performance.
devc1 wrote:
but I would want to optimize the Schedule(), malloc() and free()
In those cases, don't optimized code, optimize the algorithm and
then the code.
vvaltchev wrote:
Then, people start to do benchmarks and look for "low-hanging fruits" to optimize. That's way too late.
Yeah, that's a big problem these days.
My personal philosophy about performance is that instead of "premature optimization is the root of all evil", premature micro-optimization is the root of a lot of evil.
devc1 wrote:
I don't (...) know why Windows, languages such as python, and companies are making all these huge and vast performance losses.
Python is actually pretty fast and more than acceptable for some (e.g., I/O bound) applications. I do agree that Python is overused, however.
devc1 wrote:
You have a (...) multi-core 4000000000 GHz CPU powered with the latest SIMD technologies and you still can't make fast applications.
You need to know that CPU performance isn't nearly as significant in many applications these days as it was before. Most tasks (such as a web server, a web browser, and other things) are actually I/O bound, meaning that the CPU spends most of its time idle and most time is spent waiting around for memory or the disk, which is significantly slower than CPU. Judicious use of disk and memory is key to fast applications these days. Of course some application's performance is bound by the graphics card (3D rendering, video editors, video games) and others are still CPU-bound (primarily software compilation and scientific number crunching, but even the latter is being moved to GPUs. Look up GPGPU). But most of the time, the disk and memory is the bottleneck.
For info on judicious use of memory, look at this research paper:
https://people.freebsd.org/~lstewart/articles/cpumemory.pdfP.S. Mods, could you please split off this discussion?