Program w asemblerze wyglądający i robiący dokładnie to samo co odpowiednik napisany pod bcb6 wykonywał się w 1.5 minuty. Natomiast wersja w c++... po 2 godzinach zrezygnowałem - obliczony przeze mnie czas ukończenia pracy programu to 70 godzin!!! A wszystko przez stopień skomplikowania silnika VCL.
Ten odpowiednik jednak chyba nie byl zupelnym odpowiednikiem... Nie wiem, a nie dales niechcacy "refresh" po namalowaniu kazdego piksela??? Oczywiscie nie posadzam Cie o tak glupi blad, ale problem raczej jest kwestia podobnej pomylki niz samego jezyka, czy nawet biblioteki. VCL szybki nie jest, ale nie wmowisz mi, ze ma narzut kilkasetkrotny ponad WinAPI.
Sam kopilator borlanda też wybitny nie jest. Moim zdaniem jeśli chodzi o c++ gcc rulez :)
No nie jest. Ale jesli wierzyc benchmarkom, gcc jest akurat pod tym wzgledem jeszcze gorsze. Chyba najlepsze sa VC++ i darmowy Intel C++ Compiler.
DISKLAJMER (off-topic): Benchchmarkom z sieci generalnie nie nalezy wierzyc. Gdzies znalazlem glupi benchmark, ze Java jest tak samo szybka jak C (!). Gdzies indziej znalazlem inny benchmark, ktory twierdzil, ze tamten benchmark jest zly i ze Java jest 200-300% wolniejsza. Nawet sie dalem nabrac, dopoki nie przetestowalem na wlasnej skorze 2 syst. baz danych: Derby (java) i PostgreSQL (C). Ten pierwszy byl 100-400 razy wolniejszy, MIMO tych samych prawie algorytmow. Moze cos pokopali w tym derby, ale nikt mi juz nie wmowi, ze Java kiedykolwiek bedzie choc w polowie tak szybka jak C/C++.
Wracajac do tematu glownego: Jesli to ma byc jakas animacja, ze b. czesto musisz ja odswiezac, to lepiej napisz to w OpenGLu albo DirectX lub czymkolwiek dedykowanym do grafiki. Api Windows nie jest dostosowane do zbyt czestego odswiezania. 10 klatek / s tym wycisniesz, ale nie wiecej. Sluzy raczej do wyswietlania statycznych tresci lub malych animacji np. emotikony na tym forum, ale nie do gier 3D skladajacych sie z setek obiektow.