turistautak.hu

Előzmények

Kolesár	hozzászólásai \| válasz erre \| 2008.11.07 16:15:20 (24421)
Fájlba írást kipróbáltam, linuxon nem volt gyorsabb, mint a memória. [előzmény: (24419) Trackman, 2008.11.07 16:00:26]

Trackman

hozzászólásai | válasz erre | 2008.11.07 16:00:26 (24419)

Amely nyelv nincs külön string-összefűzésre optimalizálva, az rendszerint négyzetes futásidőt produkál az összadás darabszámára nézve.
Az
$a.='1234567890';
hatására malloc,bcopy,bcopy,free hívások keletkeznek. Az első copy hossza egyre nő, ahogy nő a string.
Úgy lehet nagyon jelentőset javítani rajta, hogy "fában" adjuk össze. Külön segít, ha tudjuk előre, hogy ? összeadás lesz.
Egy kis pascal-pszeudokód szerű:

sqrt:=<(int)összeadásszám gyöke>
result:='';
bs:='';
i:=0;
while (van még sor) do
begin
  sor:='<részösszeadandó string valahonnan>';
  bs:=bs+sor;
  i:=i+1;
  if i > sqrt then
  begin
    i:=0;
    result:=result+bs;
    bs:='';
  end;
  ...
end;
result:=result+bs;

Ha sqrt nem ismert, akkor érdmes a várható érték gyökével közelíteni. Konstans 100 is pl. sokat segíthet.

Vagy jó megoldás még, ha meg tudod oldani, hogy ne stringet adj össze, hanem file-ba írd folyamatosan a kis darabokat. Az a pufferek miatt nagy összeadás-darabszám és nagy méretű eredmény esetén sokat javíthat.

[előzmény: (24377) Kolesár, 2008.11.07 09:55:10]

Kolesár

hozzászólásai | válasz erre | 2008.11.07 09:55:10 (24377)

Újabb észrevételek az .mp fájl elkészülésének sebességhez:

1. A PHP string-kezelésének sebessége nagyon függ a gép architektúrájától. A gépem Penium M, jelenleg 600 Mhz-en, 1MB L2 cache, Windows XP, PHP 4. Egy nagy stringösszefűzés 30 ezer példányban futtatva 40s. Ugyanez a szerveren 0.11s, majdnem három nagyságrend a különbség.

2. Ugyanezen a szerveren PHP 4 alatt 0.11s, PHP 5 alatt pedig 0.05s. Valószínűleg, hogy nem csak a verzió befolyásolja, hanem az is hogy milyen fordítóval, mire optimalizálva készült, mindenesetre itt mindkét PHP debian csomagból van.

3. Képes nem-lineáris lassulásra egy adott méret felett. A saját gépemen 10e művelet 4s, 15e művelet 9s, 20e művelet 17s, 30e művelet 40s. A szerveren lineárisnak tűnik még nagyobb méreteknél is.

Nagyon fontos megvizsgálni ezeket, mielőtt nekiállunk feleslegesen alkalmazkodni a jelenlegi helyzethez.

[előzmény: (24376) Kolesár, 2008.11.07 09:23:30]

Kolesár

hozzászólásai | válasz erre | 2008.11.07 09:23:30 (24376)

Sikerült csökkentenem a letöltések időigényén, így nagyobb eséllyel férnek bele a rendelkezésre álló időbe. A felületeket eddig letöltés közben szedte össze a tájegység körvonala alapján, de ez 20.000+ poligonnál már nem volt tartható. Programmal beírtam a tájegységet minden poligonba, innentől kezdve ez a történet a másodperc töredékévé vált.

Egyúttal összeszedtem, mi minden okozhat sikertelen letöltést:

1. PHP timeout, ami a download.php-ben jelenleg 180s, vagyis 3 perc.

2. TCP timeout, ami mindenkinél annyi, amit beállít. Az én routeremen itthon nemrég átállítottam az alapértelmezett 3600 másodpercről 30 másodpercre, innentől kezdődtek a bajok a raszterizálóval. Amikor ugyanis ennél többet kellett várnia a szerverre, megszakadt a kapcsolat. Nem volt egyszerű rájönnöm, mert a gépemen nem látszott nyoma, kint maradt a homokóra a Firefoxban. Visszaállítottam 600 másodpercre.

3. Felhasználói türelmetlenség, vagyis ha nem bírja kivárni.

[előzmény: (24369) alnibell, 2008.11.06 22:30:17]

alnibell

hozzászólásai | válasz erre | 2008.11.06 22:30:17 (24369)

Igen, én követtem el azonnal a feltöltési kísérlet után, mert nem kaptam visszajelzést a feltöltés sikerességéről és mert nem tudtam ellenőrzés végett újból letölteni a tájegység mp-jét. Azaz nem tudtam ellenőrizni, megérkezett-e minden, s hogy jó-e?

ad. #24366 és #24367
Köszönöm az ellenőrzést!
A nyílt, káposztaföldek közötti, 1 kilométeres szakaszon tényleg nincs jelzés, de nincs is mire felfesteni. Ellenben tévedésből letérni sem lehet róla.
A zárolást most feloldom.
Majd még próbálkozom egy nyugalmasabb időszakban a bakony.mp letöltésével. Hátha sikerül!
Mégegyszer köszönöm!

[előzmény: (24365) fa-peti, 2008.11.06 21:46:43]

fa-peti	hozzászólásai \| válasz erre \| 2008.11.06 21:46:43 (24365)
Te zároltad megint a bakonyt. Látod az utakat az mp-ben amiket berajzoltál? Az mp-ben már elvileg látszania kéne, a Garminon lesz csak holnap ellenőrizhető. Én most néztem vissza a Börzsöny-Pilis csatlakoztatásom, és már az látszik, amit feltöltöttem. Nézd meg, hogy szerepel-e az mp-ben amit szerkesztettél. [előzmény: (24364) alnibell, 2008.11.06 20:12:31]

alnibell

hozzászólásai | válasz erre | 2008.11.06 20:12:31 (24364)

Fontos!
A nagy készülődés közben felhívnám a szakértők figyelmét az itteni [24328]-as hozzászólásomra!
Nem tudom, megérkezett-e a bakony[11]_mo.mp modonly fájl, a tartalma átvezetésre került-e az adatbázisban? Az újdonságok között olvasható a feltöltés tájékoztató adatlapja, de ellenőrizni egyelőre nem tudom, teljesült-e a feltöltés. A tájegység -ismét- zárolva van, hogy az eddigi munka ne vesszen el.
Mi legyen? Ha nem töltődött fel a tartalom, akkor küldjem el a 171kB-os fájlt az arra vállalkozónak feltöltésre?

Felhasználónevedet és jelszavadat a geocaching.hu oldalon is használhatod!

[ kezdőlap ] [ térkép ] [ + felmérések ~ ] [ + útvonalak ~ ] [ + poi ~ ] [ belépés ] [ faq ] [fórum] [email]

A weboldal működése és tartalma folyamatos fejlesztés alatt áll, köszönettel vesszük az észrevételeket a fejlesztési ötletek oldalon.
A turistautak.hu-ra feltöltött track-eket és a letölthető térképeket, azaz térképi adatbázist az ODbL licencnek megfelelően bárki használhatja.
Minden egyéb anyag előzetes írásbeli engedély nélkül csak magáncélra használható fel. jogi tudnivalók