Hej! Pytanie dokładnie jak w temacie - czy są jakieś narzędzia do tego? Dla języka Java.
0
0
Dodam, że jest to program pytający użytkownika o dane, liczący coś (pewne działania( i wyświetlający wyniki, zupełnie konsolowy program. Mam limit pamięci i czasu wykonania, a nie wiem, jak zmierzyć, ile aktualnie mój program obu wyciąga.
0
Wiem że czas da się zmierzyć:
System.CurrentTimeMills();
ta metoda daje Ci aktualny czas, bez problemu możesz obliczyć ile trwa twój program.
Co do pamięci nie wiem.
0
Profiler i sampler. Powinny być dostępne z poziomu IDE.
0
Użyłem profilera po raz pierwszy w życiu, czy ktoś może pomóc w interpretacji wyników?
Rozumiem, że tu: 
mój program cały wykonuje się 5,37 sekund?
Oraz, tu, że 
wykorzystuje 6324240 B pamięci?
To teraz pytanie - jak to zbić, zmniejszyć? (kodu nie mogę pokazać) :P
0
I czy to np. uwzględnia szybkość wpisywania danych przez użytkownika, czy tylko same obliczenia? Bo wiem że wczytywanie (tzn. domyslam się) może bardzo wydłużyć rzeczywisty czas wykonywania
0
Wygląda na to, że używasz domyślnej konfiguracji profilera. Zrób sobie nową to dojdzie ci możliwość sprawdzania czasu procesora, tzn dojdzie kolumna "Time (CPU)".
Jak już będziesz miał kolumny Time i Time CPU to wtedy:
- Time oznacza rzeczywisty czas spędzony w danej metodzie (a więc także metod wywoływanych z tej metody),
- Time (CPU) oznacza ile czasu CPU cokolwiek robił w danej metodzie,
Jeśli masz np program który jedyne co robi to czeka na wejście od użytkownika, a potem wypisuje hello worlda, to dostaniesz duże Time, ale małe Time (CPU). Dzieje się tak ponieważ podczas czekania na wejście od użytkownika procesor jest uśpiony lub zajmuje się innymi procesami, wobec czego czas czekania nie wlicza się do Time (CPU).
Jeszcze bardzo szybko wyjaśnię różnicę pomiędzy samplerem a profilerem:
- sampler co jakiś czas sprawdza ślad stosu (stack trace) - tzn konkretnie stos wywołań i na tej podstawie tworzy statystyki nt czasów wykonywania funkcji,
- profiler instrumentuje kod, tak by liczenie czasu odbywało się zawsze i wszędzie (no może nie aż tak, tzn jest to konfigurowalne),
Oba mają swoje wady i zalety: - zaletą profilera jest to, że sprofiluje wszystko co chcemy,
- wadą profilera jest to, że dodatkowy kod mierzący czas może w znaczący sposób zaburzyć wyniki, wobec czego trzeba być ostrożnym, zwłaszcza przy profilowaniu krótkich metod,
- zaletą samplera jest to, że nie wpływa na czas wykonywania metod,
- wadą samplera jest to, że potrzebuje dużo sampli (tzn próbek), a co za tym idzie dużo czasu, by z sensownym prawdopodobieństwem zebrane wyniki mniej-więcej pokrywały się z rzeczywistością,
Co do wykresu sterty to masz tam dwa wskaźniki:
- rozmiar sterty - to powinno być zawsze zauważalnie większe niż średnie zużycie, by nie tracić zbyt dużo czasu na GC; zmiana rozmiaru sterty jest tylko przy okazji GC
- zajętość sterty, czyli aktualna ilość śmieci i żywych obiektów; aktualne śmiecie zostaną wyrzucone przy następnym GC,
To są podstawy w zasadzie jeśli chodzi o profilowanie aplikacji. Polecam poczytać jakieś usystematyzowane materiały o tym.
Dodam jeszcze, że sprawdzanie czasu za pomocą System.currentTimeMillis() czy System.nanoTime() może mieć sens, tylko trzeba wiedzieć co się robi i jaka jest precyzja tych funkcji na twoim systemie. Można też mierzyć czas zewnętrznym miernikiem czasu i czasu procesora, np w GNU jest program "time" mierzący domyślnie czas rzeczywisty, czas procesora i czas jądra (chyba). Pod Windowsem możesz użyć np: http://encode.ru/threads/245-timer301-zip