No wlasnie. Pytanie jak w temacie. Ale najpierw kilka danych:
Program pisany od poczatku w VB5P+SP3.
Program ma zdefiniowane okolo 100 okienek .FRM i tylez procedur w kilku
modulach .BAS.
Oto wyniki kompilacji:
Kod EXE Kompilacja Szybkosc Zasoby systemu
P-Code 2,7 MB 4 min 1 30%
N-Code NO 5,5 MB 35 min 1.05 (5% szybszy) 42%
N-Code SP 5,9 MB 45 min 1.07 (7% szybszy) 40%
N-Code SZ 5,3 MB 45 min 1.03 (3% szybszy) 36%
(NO - No Optimization, SP - Optimize Speed, SZ - Optimize Size)
Program zostal zoptymalizowany (85% zmiennych to Integer i String, 10%
Long, Pozostale to Variant). Korzysta tez z okolo 40 funkcji API.
Komputer P166, 64MB RAM, Win95/OSR2
Dochodze do wniosku, ze N-Code to jeden wielki pic. Ale ciekaw jestem
waszej opinii. Co wy na to ?
Pozdrowka.
Artur.
PS. Wlasnie skonczylem urlop i wracam do aktywnego uczestnistwa w
dyskusjach na naszym rodzinnym forum. Nie pytam, czy sie cieszycie, bo
wiem, ze tak :). Serwer FTP ruszy w najblizszy poniedzialek, bo poki co
to wybywam w srode na konferencje jako jeden z jej organizatorow i nie
bedzie mnie do soboty.
A w jaki sposób przeprowadziłeś ten test? Znaczy się jak mierzyłeś
szybkość? Z zegarkiem w ręku, czy może wbudowałeś w program jakiś
stoperek?
A tak swoją drogą dość ciekawe jest to, że kompilacja P-Code daje
zdecydowanie mniejszy plik EXE, choć zasoby systemu spadają wówczas dość
drastycznie (30% to już niewiele...).
Myślę jednak, że taki test powinien być przeprowadzony na większej
ilości komputerów o różnych konfiguracjach. Wówczas można by wyciągać
jakieś konkretniejsze wnioski. Niemniej Twoje wyniki są bardzo ciekawe i
warte przemyślenia, czy rzeczywiście warto się pchać na ten N-Code.
Będąc zaciekawiony poruszonym przez kolegę tematem postanowiłem sam
przeprowadzić krótki test. Mój app skompilowany do N-Code (optymalizacja
na szybkość) miał objętość dokładnie 1.207.296 bajtów, zajmował około
10% zasobów systemowych (pomiar prosty: sprawdziłem ile jest zasobów
przed i po uruchomieniu aplikacji :). Kompilacja programu trwała około
2-3 minut.
Ta sama aplikacja skompilowana na P-Code: objętość 519.680 bajtów,
zajętość zasobów około 5%, szybkość kompilacji - ok. 10 sekund.
Wydajność skompilowanych exe-ków była porównywalna (pomiary robione "na
oko" :). Czyżby więc teoria Heretica o "picu na wodę" N-Code'u słuszna?
Może pozostali grupowicze także wykonają podobne testy (jeśli mają
jakieś większe appy - na małych programikach do obliczania kwadratu
liczby nie sensu sprawdzać :).
Aha - mój sprzęt: P200MMX, 64 MB RAM, Win95OSR2
Że zacytuję: "Będąc zaciekawiony poruszonym przez kolegę tematem ..."
chciałbym się dowiedzieć co to jest N-Code i P-Code albo gdzie znaleźć
coś na ten temat?
Jak rozumiem jest to sposób kompilacji ale poza tym nic nie wiem :(
Zibi
Zbigniew Kowalczyk
Pozwolisz, że zacytuję Podręcznik Programisty (strona 357):
"Format p-kod, czyli pseudokod, jest pośrednim etapem między
instrukcjami wysokiego poziomu w programie języka Basic a kodem rodzimym
[czyli N-Code - Native Code - przyp. mój] niskiego poziomu wykonywanym
przez procesor komputera. W czasie wykonywania, system Visual Basic
tłumaczy instrukcje p-kodu na kod rodzimy. Przez kompilowanie
bezpośrednio do formatu kodu rodzimego zostaje wyeliminowany pośredni
etap p-kodu."
Mówiąc po ludzku - teoretycznie N-Code nie powinien korzystać z DLL-i
(czyli tego "etapu pośredniego") i chodzić przez to znacznie szybciej od
P-Code'u. Jak się okazało w praktyce, anie jeden ani drugi warunek nie
został spełniony w 100% (mimo kompilacji do N-Code, nadal wymagany jest
run-timer, a szybkość jest minimalnie większa). Kompilacja do P-Code ma
tę zaletę, że exe jest znacznie mniejszy i zajmuje mniej zasobów
systemowych.
A teraz z innej beczki - czy P-Code łatwiej jest "odkompilować" od
N-Code'u? Tu zwracam się do pozostałych grupowiczów. Jeśli wiedzą, niech
piszą...
Moje skrajne przypadki dla VB5+SP3
1.Program ktorego sercem jest procedura z czterokrotnie zaglebiona petla
typu
FOR x=1 TO 100, zadnej grafiki i operacji dyskowych w czasie wykonywania.
Rezultat: N-CODE jest 7,5 razy (750%) szybszy od P-CODE.
2.Program z procedura przeszukiwania dysku "C:". Grafika w czasie
wykonywania: wyswietlanie ProgressBar. Pozostale to tylko operacje dyskowe.
Rezultat: N-CODE = 98% P-CODE. (P-CODE jest szybsze).
3.Ta sama procedura co w pkt2. z zastosowaniem funkcji API zamiast DIR.
Rezultat: N-CODE=108% P-CODE. (N-CODE szybszy ale niewiele).
Wszystkie w/w programy optymalizowane dla N-CODE na szybkosc wykonania.
Wg. mnie optymalizacja na krotki kod ma tylko sens dla ActiveX i DLL.
Pozdrawiam.
Wiesiek.