Thread View: pl.comp.os.advocacy
8 messages
8 total messages
Started by Qrczak
Wed, 04 Mar 1998 22:04
Mała miękka wydajność a GNU wydajność
Author: Qrczak
Date: Wed, 04 Mar 1998 22:04
Date: Wed, 04 Mar 1998 22:04
48 lines
2832 bytes
2832 bytes
Przeprowadziłem właśnie mały test sortowania. Wziąłem przykładowy,
pięciomegabajtowy plik tekstowy, zawierający 134024 linijki
(był to interrup.lst).
Pierwsza próba: Excel. Najpierw miło mnie zaskoczył wygodnym importem
pliku tekstowego - zgadywał, w których kolumnach zaczynają się
poszczególne pola, i pozwolił to ręcznie dostroić. Jednak... "Plik nie
został załadowany całkowicie". No tak, arkusz Excela ma tylko 16384
wiersze...
Spróbowałem Worda - on przecież nie ma takiego ograniczenia. Owszem,
załadował się, ale kiedy chciałem go posortować, stwierdził, że
"Dokument jest zbyt duży, aby program Word mógł go obsłużyć".
A przecież mam 32 MB RAMu i hektary pamięci wirtualnej!
DOS ma komendę sort... Poszło! Sortował przez 40 sekund. No i fajnie.
Program sort ma 25 kB. Niech żyje!
Ale on zapewne używa tylko z pamięci rzeczywistej, jak to DOS - nie
wykorzysta więc w pełni zasobów komputera. No i nie ma GUI :-)
Musi być coś pod Windowsy! I przypomniałem sobie, że mam jeszcze
Accessa. On na pewno jest przystosowany do dużych baz danych.
Udało mi się zaimportować to do Accessa. Posortował. Zajęło mu to 50
sekund. Hmm...
Wracam do Linuxa, w którym jest GNU sort. Kiedyś sortowałem nim już
pięćdziesięciomegabajtowe pliki. Ten posortował w dwanaście sekund!
Z wynikiem w pliku, bo do /dev/null wychodzi około 9 sekund.
Sprawdziłem też tego samego GNU sorta, ale w wersji DOSowej. Tak samo
szybko, nawet ciut szybciej.
Mimo że czytał go jako plik tekstowy, który, jak niektórzy twierdzą,
jest wolniejszy w obsłudze od binarnego - a Access miał go już w
pamięci, w jakiejś najwygodniejszej dla siebie formie (nie liczyłem
czasu importowania), i wynik teoretycznie też mógł trzymać tylko
w pamięci.
Wspaniały mały miękki program za grube pieniądze okazał się w takiej
drobnej sprawie jak sortowanie cztery razy wolniejszy od darmowego
programu sortującego pod Linuxem.
--
QRCZAK
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrczak.home.ml.org/
Re: Mała miękka wydajność a GNU wydajnoś ć
Author: Robert Maron
Date: Thu, 05 Mar 1998 11:40
Date: Thu, 05 Mar 1998 11:40
12 lines
1370 bytes
1370 bytes
On Wed, 4 Mar 1998 23:04:20 +0100, Qrczak <qrczak@knm.org.pl> wrote: : Wspaniały mały miękki program za grube pieniądze okazał się w takiej : drobnej sprawie jak sortowanie cztery razy wolniejszy od darmowego : programu sortującego pod Linuxem. nie pisz 4 razy, tylko sprawdz jaka jest zlozonosc, wez plik 10x wiekszy i ponow proby, dopiero wtedy bedzie wiadomo cos ciekawego... robert -- robmar@mimuw.edu.pl http://zls.mimuw.edu.pl/~robmar/ K: How long have you had the feeling that you are an extraterrestrial person? P: It started shortly after my birth on Aldebaran.
Re: Mała miękka wydajność a GNU wydajnoś ć
Author: Paweł Paroń
Date: Thu, 05 Mar 1998 11:56
Date: Thu, 05 Mar 1998 11:56
12 lines
1327 bytes
1327 bytes
On 5 Mar 1998 11:40:30 GMT, Robert Maron <robmar@lipa.mimuw.edu.pl> wrote: >On Wed, 4 Mar 1998 23:04:20 +0100, Qrczak <qrczak@knm.org.pl> wrote: >: Wspaniały mały miękki program za grube pieniądze okazał się w takiej >: drobnej sprawie jak sortowanie cztery razy wolniejszy od darmowego >: programu sortującego pod Linuxem. >nie pisz 4 razy, tylko sprawdz jaka jest zlozonosc, wez plik 10x wiekszy i >ponow proby, dopiero wtedy bedzie wiadomo cos ciekawego... Znaczy ma próbowac z plikiem 50MB? Który z malomiekkich produktów potrafi wczytac 50MB plik? ;) Pawel
Re: Mała miękka wydajność a GNU wydajnoś ć
Author: Robert Maron
Date: Thu, 05 Mar 1998 21:19
Date: Thu, 05 Mar 1998 21:19
10 lines
1283 bytes
1283 bytes
On 5 Mar 1998 11:56:40 GMT, Paweł Paroń <pawelp@rodan.rodan.pl> wrote:
: Znaczy ma próbowac z plikiem 50MB? Który z malomiekkich produktów potrafi
: wczytac 50MB plik? ;)
no access chyba powinien...
robert
--
robmar@mimuw.edu.pl http://zls.mimuw.edu.pl/~robmar/
Basically, it is as simple as that.
What you do with this knowledge is a different matter, of course.
Re: Mała miękka wydajność a GNU wydajnoś ć
Author: Rafał Sobiczewski
Date: Thu, 05 Mar 1998 23:43
Date: Thu, 05 Mar 1998 23:43
13 lines
1256 bytes
1256 bytes
Robert Maron napisał(a) w wiadomoci: ...
>On 5 Mar 1998 11:56:40 GMT, Paweł Paroń <pawelp@rodan.rodan.pl>
wrote:
>: Znaczy ma próbowac z plikiem 50MB? Który z malomiekkich produktów
potrafi
>: wczytac 50MB plik? ;)
>no access chyba powinien...
No właśnie - CHYBA powinien! ;-)))))))
Ale czy POTRAFI?
Pozdrawiam
Rafał
Re: Mała miękka wydajność a GNU wydajność
Author: Marcin Wieczorek
Date: Fri, 06 Mar 1998 22:10
Date: Fri, 06 Mar 1998 22:10
12 lines
1298 bytes
1298 bytes
Qrczak <qrczak@knm.org.pl> napisał(a): >Ale on zapewne używa tylko z pamięci rzeczywistej, jak to DOS - nie >wykorzysta więc w pełni zasobów komputera. No i nie ma GUI :-) >Musi być coś pod Windowsy! I przypomniałem sobie, że mam jeszcze >Accessa. On na pewno jest przystosowany do dużych baz danych. A tak z czystej ciekawości. Sprawdź jeszcze UltraEditem. Sam bym to zrobił ale nie mam Twojego pliku testowego. ___________________________________________ Marcin Wieczorek ( T-1000 ) wieczor@polbox.com www.polbox.com/w/wieczor DELPHI FAQ http://www.kki.net.pl/t1000
Re: Mała miękka wydajność a GNU wydajność
Author: Qrczak
Date: Sat, 07 Mar 1998 06:15
Date: Sat, 07 Mar 1998 06:15
12 lines
1140 bytes
1140 bytes
On Fri, 6 Mar 1998, Marcin Wieczorek wrote:
> A tak z czystej ciekawości. Sprawdź jeszcze UltraEditem. Sam bym to
> zrobił ale nie mam Twojego pliku testowego.
Niestety nie mam UltraEdita.
--
QRCZAK
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrczak.home.ml.org/
Re: Mała miękka wydajność a GNU wydajność
Author: Qrczak
Date: Sat, 07 Mar 1998 13:32
Date: Sat, 07 Mar 1998 13:32
45 lines
3038 bytes
3038 bytes
On 5 Mar 1998, Robert Maron wrote:
> nie pisz 4 razy, tylko sprawdz jaka jest zlozonosc, wez plik 10x
> wiekszy i ponow proby, dopiero wtedy bedzie wiadomo cos ciekawego...
To faktycznie może też być ciekawe. Z tym że dziesięć razy większy
odpadł, bo 160 MB wolnego miejsca na dysku nie wystarczyło Accessowi do
posortowania 60MBowego pliku. GNU sort zajął tymczasowo 66 MB.
Mam dwa pliki tego samego charakteru (ls -lR): pierwszy ma 100000 linii
i 6 MB, a drugi - 500000 linii i 30 MB.
GNU sort sortował pierwszy przez 17 sekund, a drugi przez 117 sekund.
Pięć razy większy plik sortuje 6.9 razy dłużej. Algorytm rzędu n log n
dałby tutaj 5.7 razy dłużej. Hmm... Nie chce mi się ściągać źródeł, żeby
zobaczyć, jaki algorytm stosuje GNU sort. Patrzyłem na tworzone przez
niego tymczasowe pliki i IMHO doskonale pasowałby merge sort na wysokim
poziomie i cokolwiek na niskim. Może większa niż trzeba różnica bierze
się z tego, że przy dużych plikach procentowo więcej operacji jest
robionych na dysku zamiast w pamięci?
Microsoft Access sortował pierwszy plik przez 54 sekundy (3.2 raza
dłużej niż GNU sort), a drugi przez 375 sekund (też 3.2 raza dłużej).
Wygląda na to, że algorytm jest tego samego rzędu, a GNU sort jest po
prostu lepiej napisany pod względem technicznym.
Jeszcze jedno. Gdybym tego nie zobaczył na własne oczy, tobym nie
uwierzył... Access gubi rekordy! Plik z 500000 liniami po wczytaniu do
Accessa ma tylko 497755 rekordów!!! Wziąłem pierwsze 100 linii.
W Accesie zrobiło się z tego 97 rekordów. Sprawdziłem, że po prostu
zgubił pewne trzy linie ze środka :-o
Kiedy zaimportowałem ten plik z podziałem na pola, który zaproponował mi
domyślnie (do sortowania wczytywałem całe linie jako pojedyncze pola
tekstowe), to zgubione linie były jakoś doklejone do sąsiednich...
Jeśli będzie mi się chciało, to spróbuję zrobić jakiś możliwie krótki
testowy plik, żeby każdy mógł się sam o tym przekonać. Jest to Access
z Offica 95.
--
QRCZAK
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrczak.home.ml.org/
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads