witam,
niedawno zakupilem sobie dysk ssd. nie ukrywam, ze jednym z czynnikow bylo przeczytanie wielu bardzo pozytywnych wpisow na in4;)
do rzeczy:
system przyspieszyl znacznie. wszystko sie szybciej uruchamia.
tak sie sklada, ze zawodowo pracuje przy komputerze. aktualnie uzywam netbeansa 7.3 w polaczeniu z glassfishem. i tutaj pojawia sie moj lekki zawod poniewaz czasy budowania projektu i deploy'a wcale nie przyspieszyly.. moze 10 sek. i teraz pytanie.. czy moze ja cos zle zrobilem czy tak ma byc?

dysk: kingston v300
ram: 6gb
procek: i5 pierwszej generacji

dziekuje i pozdrawiam

U mnie budowa projektów też nie jest jakoś ekstra szybka.
Tutaj głównie winą może być to, że budowane pliki są malutkie - one mają nie więcej niż pół megabajta, się domyślam, a jak wiadomo, testy dysków SSD pokazują, że operacje na małych pliczkach nie są szybkie.

Musiałbyś budować projekt, w którym pliki źródłowe, wynikowe jak i sama aplikacja musiały by mieć po kilka - kilkanaście MB abyś zobaczył różnicę, bo w tak dużych plikach, zobaczysz, że na dysku SSD są szybciej przetwarzane niż na HDD.

Aby przyśpieszyć budowę projektów, musiałbyś w jakiś sposób włączyć wielozadaniowość aplikacji. Przy kompilatorze MinGW to opcja -j Liczba_Rdzeni, a w przypadku kompilatora od MS, zastąpienie nmake, narzędziem jom (jak dobrze pamiętam). NetBeans to chyba Java, ale tutaj nie znam tych operacji.

Skoro wymiana dysku nie przyspieszyła czasów kompilacji, to prosty wniosek, że na ten czas mają wpływ również inne czynniki - np. prędkość CPU i RAM.

Otwórz manager zasobów podczas kompilacji i zobacz co jest używane.

Przeprowadziłem właśnie prosty eksperyment i podczas kompilacji dużego projektu CPU wykorzystywane jest przez większość czasu powyżej 90%. Co prawda Visual Studio, a nie NetBeans, ale podejrzewam, że mechanizm jest podobny.

troche smutek:/

[LINK] tutaj ktos pisal ze mu bardzo mocno przyspieszylo.. myslalem ze u mnie bedzie podobnie;) no ale coz nie mozna miec wszystkiego:)

W zasadzie @Inferno wyczerpał temat - duża liczba małych plików nie działa korzystnie na wydajność SSD. Ja pracuję na NetBeans'ie w php - symfony. Po przesiadce na SSD AGILITY 3 jest spora poprawa ale nie ma szału - SSD działa bardzo przyhamowany bo TYLKO w trybie SATA 1 - stary komputer.
Podobnie wygląda to w Eclips'ie.

Oczywiście wyłączyłeś buforowanie, defragmentację i indeksowanie ?

@Inferno
Operacje na małych pliczkach i tak są o niebo lepsze niż na normalnych talerzowcach.
@burky
A czemu akurat wybór V300? To nie jest jakaś specjalnie wydajna konstrukcja. Dużo lepiej radzą sobie Micron/Sandisk/Crucial czy też nowe OCZ. Zawsze przy zakupie dysku trzeba się kierować wydajnością przy zapisach 4k i IOPS. Szczególnie przy tym jeśli dysk ma być jako narzędzie pracy.

@burky pewnym rozwiązaniem jest jeszcze stworzenie ramdysku i przekierowanie tam katalogów potrzebnych do kompilacji i linkowania. w ekstremum to można tam przy starcie systemu wrzucić całe IDE - wtedy dostaniesz kopa, ale kosztem bezpieczeństwa, nad którym trzeba by posiedzieć... czym tworzysz programy i jakiego typu?

okej czemu v300 - cena/jakos niejednokrotnie chwalony na in4
pisze w javie

nie jest az tak zle zeby jakos specjalnie kombinowac. po prostu spodziewalem sie wiekszego kopa w netbeansie.

build - 1:30

deploy - 2:30

nie ma tragedii;) ale moze mi cos podpowiecie
@szmalik
indexowanie i defragmentacja wylaczona. wylaczylem tez pagefile i hibernacje
ale co to jest buforowanie?

@burky
[LINK]

@burky W takich chwilach przydaje się JRebel build = deploy

Tylko drogie cholerstwo

lece na wersji trial narazie :) jrebel jest spoko^^

SSD jest fajne i szybkie, ale nie jest lekarstwem na wszystko.
Mi na przykład startuje troszkę szybciej IDE :) A co do kompilowania projektów, nie robiłem jakoś specjalnie testów, ale na odczucie, przy SSD jest troszkę szybsze ...

IDE wstaje super szybko... 8 sek netbeans ^^
na buildzie i deploy'u tez mam zysk ~10-20 sek

nie jest zle ale chcialoby sie lepiej;)

@pi_nio
To nic nie pomoże, bo ograniczeniem nie jest tu ilość operacji I/O. Podobnie wymiana na SSD nie doda klatek w grze.
No ale czasy kompilacji to przecież nie wszystko. Ogólny wzrost responsywności jest oczywisty i również przydatny w programowaniu (np. przy przełączaniu się pomiędzy dokumentacją, wyszukiwaniem rzeczy w necie itp.).

@szmalik
to buforowanie ma byc wlaczone czy wylaczone? w roznych tutorialach pisza ze raczej wlaczone..wiec jak to jest?

jesli chodzi o programowanie to oczywiscie ze wzrost responsywnosci jest super pomocny. reasumujac..dysk ssd to dobry zakup;) mam nadzieje ze tak samo bede mogl powiedziec za jakis czas;)

Przy buildowaniu liczy się najbardziej procek - sprawdź sam jakie masz obciążenie
Co to było odczytać paręset drobnych plików, gdy kompilator potrzebuje w tym czasie dużego papu od CPU?

i5 1st gen znaczy dokładnie jaki? 750, 65x?
Podkręcony jest? Jak nie to te 50% czasu można by zaoszczędzić...

to jest notebook:) acer 5820tg:) w/g specyfikacji jest tutaj Intel Core i5 430M

Aha no to cudów nie będzie. Jak piszą wyżej - kompilator zjada CPU i nic nie zrobisz. Chyba że [LINK] [LINK] albo jeśli Fasolki obsłużą to [LINK] choć cena niefajna i nie wiem jak z GPU...

I tak ten Acer daje radę (sam mam). Niestety powyżej FHD robi się już różnie i sporo gier nie wydala, co nie zmienia faktu że mój trzyma się niesamowicie. Po 2,5 roku bateria mi wczoraj pokazywała 5-6h na wifi. Niech któryś inny laptop z takim stażem spróbuje to pobić.