Ponownie marnuje czas na rozmyślaniu o rzeczach nie mających znaczenia. Czy powinienem z góry zaalokować x obiektów jeśli x jest znane, mimo ze wiem ze każdy z obiektów i tak wykona call do new/malloc na który nie mam wpływu i zaalokuje małą ilość pamięci która trafi prawdopodobnie gdzieś na koniec mojego zaalokowanego bloku? Gdybym allokował każdy obiekt pojedyńczo sam obiekt oraz jego małe dane które owy obiekt potrzebuje byłyby prawdopodobnie blizej siebie w pamięci a tak pierwszy obiekt w moim duzym bloku trzyma swoje dane gdzieś po wszystkich obiektach na koncu, daleko w pamięci. Z drugiej strony alokując każdy pojedynczo mogę tylko pogorszyć i porozrzucać obiekty po pamięci zamiast w ciągu, ale dane byłyby blizej siebie. Co robić?! Ile nanosekund tracę?!?!?!
http://c2.com/cgi/wiki?PrematureOptimization
"premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
Gdybym allokował każdy obiekt pojedyńczo sam obiekt oraz jego małe dane które owy obiekt potrzebuje byłyby prawdopodobnie blizej siebie w pamięci a tak pierwszy obiekt w moim duzym bloku trzyma swoje dane gdzieś po wszystkich obiektach na koncu, daleko w pamięci.
A masz jakiś dowód na poparcie tej hipotezy, czy tak sobie gdybasz?
Generalnie nie staraj się być sprytniejszy od kompilatora, bo nie wiesz jakie optymalizacje może stosować. Pomijając już fakt, że nawet jeśli gdybanie jest prawdziwe to zaoszczędziłeś tyle czasu, że hoho.
Napisz tak, żeby było czytelnie. Stawiam 2l jacka danielsa, że profiler nie wskaże tworzenia Twoich obiektów jako bottlenecków
Co robić?! Ile nanosekund tracę?!?!?!
Proponuję użyć profilera i zmierzyć.
vector<> + reserve() - jeżeli profiler nie wskaże inaczej to więcej nie dotykać.
Tu akurat jest problem w ktorym mozna niezle wtopic nie zastanawiajac sie od razu.
Byl na ten temat artykul w "Programista" i jest jakas prezentacja z optymalizacji:
https://channel9.msdn.com/Events/Build/2014/2-661
Od 40 minuty mniej wiecej (chociaz mozna obejrzec calosc).
Ja polecam www.akkadia.org/drepper/cpumemory.pdf
Rozwijając komentarz do RAS/CAS (a nie do całości) bo za dużo tego:
Chodzi mi o to, że gdybym już miał schodzić w swojej pracy z Javą na tak niski poziom, to poszukałbym czegoś o NUMA, GC lub JVM.
RAS/CAS to takie za przeproszeniem "pierdoły o żabach", które nawet mi w C/C++ się nie przydały (nie mówiąc już o ASM w którym HPC nie dotykałem nawet).
NUMA:
http://www.cs.umd.edu/~hollings/papers/ipdps05.pdf
http://performanceterracotta.blogspot.com/2012/09/numa-java.html
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#numa
http://frankdenneman.nl/2015/02/27/memory-deep-dive-numa-data-locality/
DRAM
Jak machając bitami zrobić włam w Java/JavaScript: http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
GC
(stare) http://archive.oreilly.com/pub/a/onjava/2006/11/01/scaling-enterprise-java-on-64-bit-multi-core.html