hobocti77x_ dokładnie.
To co w moim doświadczeniu przyspiesza programy BASICa to (benchmarki są wykonane przeze mnie):
- Usuwanie spacji i REM
- Używanie zmiennych zmiennoprzecinkowych zamiast zmiennych całkowitych (jak A%) daje 50% szybsze obliczenia a używanie zmiennych zmiennoprzecinkowych zamiast stałych (2*3) daje spory wzrost szybkości obliczeń, szczególnie przy ułamkach (ponad 4 razy przy operacji na 2 ułamkach) i złożoności obliczeń (5-6 razy i więcej przy czterech i więcej argumentach). Co ciekawe używanie stałych w instrukcjach FOR, TO i NEXT nie ma to znaczącego wpływu na szybkość tej pętli.
- Jednoliterowe zmienne, szczególnie w przypadku wymagających szybkości części kodu.
- Kropka . zamiast zera (w samym zerze a nie np. 2.. - dwieście)
- Gdzie się tylko da komendy w jednej linii programu przedzielone : dwukropkiem
- Jak najmniejsze numery linii (0, 1, 2, 3.... a nie 10, 20, 30 itd.). Do tego najbardziej wymagające przyspieszenia części powinny być z przodu programu (mieć jak najmniejsze numery linii).
- Jeśli to możliwe wpisywanie samego NEXT bez nazwy zmiennej daje do 25% w przypadku pustych pętli, realnie około 1-2%.
- Przy programach obfitych w zmienne inicjowanie krytycznych zmiennych jako pierwsze to naprawdę dobry pomysł. Przy programie z ponad 100 zmiennymi i 7 ponad 1000 elementowymi tablicami (BASIC RAM tak dopchany, że łącznie po uruchomieniu programu zostało 5 bajtów z 38 KB) kod: A=INT(RND(.)*16):POKE1024+A,64 wykonuje się ponad 50% szybciej, gdy zmienna a jest zainicjowana na początku a nie jako ostania. Przy złożoności obliczeń i ilości argumentów to się nakłada tak, że C=B/A jest ponad 3 razy szybsze gdy te zmienne są deklarowane jako pierwsze a nie ostatnie. Deklarowanie tablic jako ostatnie przyspiesza dostęp do zmiennych. Deklarowanie dużej ilości zmiennych zalecam robić sposobem DIM A,B,C,D,... zamiast A=.:B=.:C=.
=.:...., bo zajmuje trochę mniej miejsca i jest 2x szybsze. Jeśli początkowa wartość inicjowanej zmiennej ma być inna niż 0 (zero) to drugi sposób jest konieczny (A=8).
dekanex: Mam potencjalnie fajne rozwiązanie twojego problemu, choć nie bez wad.
A co jakby zamiast jednego pliku SEO dać osobny do każdego dema?
Program katalogujący najpierw przeczesuje folder i zbiera listę elementów. Po każdym elemencie kolejno produkuje plik SEQ pod nazwą plik 001,plik 002,... a nich nazwę elementu. Na końcu dodaje plik 000 z liczbą elementów znalezionych podczas tego przeczesywania.
Wykonać to można tak:
i dalej:
Kod: Zaznacz cały
open1,8,15,z$:close1:z$="@0:plik"+str$(fi)+",seq,w":open1,8,8,z$:print#1,pn$:close1
Program wczytujący demo wczytuje liczbę elementów z plik 000 i generuje losową liczbę od 1 do liczby elementów, następnie ładuje nazwę z plik _liczna losowa_ i ładuje demo. Cała filozofia i prawie natychmiastowa egzekucja. Minus to baza danych złożona z dużej ilości mikro-śmieci na dysku/folderze. Można opracować program do wywalania ich od pliku 000 do pliku _liczba w pliku 000_
co przy 20+ demkach robi się nurzące.
jeżeli zawartość karty SD jest w miarę stała to może zrobić dir do jednego pliku o ustalonej z góry nazwie i później wczytywać tylko ten plik do losowania?
