ďťż
 
dla dobrych znawcow PHP ďťż
 
dla dobrych znawcow PHP
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

dla dobrych znawcow PHP



tomm - 05-11-2005 20:27
dla dobrych znawcow PHP
  Witam,

problem jest taki, na serwerze (mowa o PHP) powinny
byc przez caly czas przechowywane pewne obiekty,
nie tylko na czas wykonywania skryptu,
nie chodzi mi tez o ich zapamietywanie poprzez serializacje,
to musi byc bardzo bardzo szybkie

dlatego pomyslalem o napisaniu wlasnego modulu do PHP,

teraz pytania:
1. czy jesli napisze taki modul, moze on sobie zyc wlasnym zyciem,
a jednoczesnie np. dostarczac jakis danych do skryptow

musi bowiem to byc w pelni dzialajacy jakby osobny program
przechowujacy dane w sobie, komunikujacy sie z baza itp

2. czy ma ktos z was praktyke w pisaniu takich modulow

3. moze jest inne rozwiazanie tego problemu, moze nie modul a jakos inaczej
ogolnie chodzi wlasnie o osobny program ale posiadajacy bardzo szybkie
i wydajne polaczenie z skryptami PHP (komunikacja np. poprzez plik,
czy baze odpada)

bede bardzo wdzieczny za wszelkie podpowiedzi

pozdrawiam,

Tomek





=?iso-8859-2?Q?=A3ukasz_Kalbarczyk?= - 05-11-2005 20:27

  tomm <tmroz1@poczta.gazeta.pl> pisze:
> 3. moze jest inne rozwiazanie tego problemu, moze nie modul a jakos
> inaczej ogolnie chodzi wlasnie o osobny program ale posiadajacy
> bardzo szybkie i wydajne polaczenie z skryptami PHP (komunikacja
> np. poprzez plik, czy baze odpada)

W systemach unixowych jest wiele możliwych sposobów komunikacji -
różne kolejki itp. PHP ma zdaje się dostęp do tych mechanizmów,
więc wystarczy, żeby zewnętrzny program tym zarządzał.
Nie wiem, czy nie po to są właśnie stworzone bazy danych...
Wszystko, co się nie mieści w pamięci, korzysta z "jakichś" plików.

--
ŁK http://moze.przeczytaj.sobie.to




tomm - 05-11-2005 20:27

  > W systemach unixowych jest wiele możliwych sposobów komunikacji -
> różne kolejki itp. PHP ma zdaje się dostęp do tych mechanizmów,

w ostatecznosci moge przez jakis port przez fopen(),
ale wtedy nie mam bezposredniego dostepu do danych

> więc wystarczy, żeby zewnętrzny program tym zarządzał.
> Nie wiem, czy nie po to są właśnie stworzone bazy danych...

baza tak jak napisalem odpada

Tomek




Krycek - 05-11-2005 20:27

  Dnia 05-11-2005 o 13:06:44 tomm <tmroz1@poczta.gazeta.pl> napisał:

>> W systemach unixowych jest wiele moÂżliwych sposobów komunikacji -
>> róÂżne kolejki itp. PHP ma zdaje siĂŞ dostĂŞp do tych mechanizmów,
>

Ja bym to zrobił tak że jest sobie zewnętrzny program działający jakośtam
+ udostępniający usługi przez powiedzmy sockety, potoki lub pamięć
dzieloną (albo dowolne inne metody zależne od stosowanego OS a spełniające
kryterium szybkości) - najlepsze chyba (o ile programy działają na tej
samej maszynie) są potoki. Komunikacje z programem z poziomu PHP
umożliwiają odpowiednie funkcje. Zrobienie dodatkowego modułu PHP nie
wydaje mi się znacznym usprawnieniem gdyż i tak będziesz musiał zrobić
podobny program działający w pętli i na rządanie udostępniający jakieś
dane do modułu. Jedynym plusem to to że taki moduł będzie korzystał z
mechanizmów komunikacji udostępnianych przez C a nie przez PHP - zważ
jednak na fakt iż wywołanie funkci w PHP do komunikacji tak naprawde jest
wywołaniem procedury napisanej w C. A swój moduł musisz obsłużyć w podobny
sposób funkcjami PHP więc moim zdaniem zysk z napisania modułu jest
niewielki w porównaniu do rozwiązania które przedstawiłem chyba że chcesz
jakoś obrabiać dane poza programem i musiałoby to spaść na PHP.

--
Krycek





tomm - 05-11-2005 20:27

  > Ja bym to zrobił tak że jest sobie zewnętrzny program działający jakośtam
> + udostępniający usługi przez powiedzmy sockety, potoki lub pamięć
> dzieloną (albo dowolne inne metody zależne od stosowanego OS a spełniające
> kryterium szybkości) - najlepsze chyba (o ile programy działają na tej
> samej maszynie) są potoki. Komunikacje z programem z poziomu PHP
> umożliwiają odpowiednie funkcje. Zrobienie dodatkowego modułu PHP nie
> wydaje mi się znacznym usprawnieniem gdyż i tak będziesz musiał zrobić
> podobny program działający w pętli i na rządanie udostępniający jakieś
> dane do modułu. Jedynym plusem to to że taki moduł będzie korzystał z
> mechanizmów komunikacji udostępnianych przez C a nie przez PHP - zważ
> jednak na fakt iż wywołanie funkci w PHP do komunikacji tak naprawde jest
> wywołaniem procedury napisanej w C. A swój moduł musisz obsłużyć w podobny
> sposób funkcjami PHP więc moim zdaniem zysk z napisania modułu jest
> niewielki w porównaniu do rozwiązania które przedstawiłem chyba że chcesz
> jakoś obrabiać dane poza programem i musiałoby to spaść na PHP.

dzieki za odpowiedz, dokladnie zrozumiales o co mi chodzi :)
co do ostatniego zdania to faktycznie niekiedy przydalo by
sie skorzystac z tego z w PHP,
wogle caly projekt jest taki, ze niektore jego fragmenty najlepiej
napisac w np JAVA (szybsze kodowanie) a inne musza byc bardzo
szybkie i tu juz raczej C zostaje

pozdrawiam,

Tomek




Pawel Rutkowski - 05-11-2005 20:28

  On 2005-11-05, tomm <tmroz1@poczta.gazeta.pl> wrote:
> dlatego pomyslalem o napisaniu wlasnego modulu do PHP,
To sie nazywa middleware
> 2. czy ma ktos z was praktyke w pisaniu takich modulow

Napewno ma...

--
Pawel Rutkowski Centauri RSC
+48 22 847 68 52 http://www.rsc.pl




Marcin Staniszczak - 11-11-2005 11:34

  Witam

Jeśli jednak zdecydujesz się na napisanie modułu, to może pomocny okaże
się mój artykuł na ten temat - odsyłam wtedy do Magazynu Internet ze
stycznia ("Zend API - gdy PHP to za mało" - da się kupić numer
archiwalny - www.mi.com.pl). Opisałem tam na prostym przykładzie
(szyfrowanie cezara) pisanie takich modułów.

Pozdrawiam
Marcin Staniszczak




tomm - 11-11-2005 11:34

 
Użytkownik "Marcin Staniszczak" <marcin.staniszczak@wp.pl> napisał w
wiadomości news:dkj7er$qv$1@atlantis.news.tpi.pl...
> Witam
>
> Jeśli jednak zdecydujesz się na napisanie modułu, to może pomocny okaże
> się mój artykuł na ten temat - odsyłam wtedy do Magazynu Internet ze
> stycznia ("Zend API - gdy PHP to za mało" - da się kupić numer
> archiwalny - www.mi.com.pl). Opisałem tam na prostym przykładzie
> (szyfrowanie cezara) pisanie takich modułów.

dzieki wielkie,
jesli by to nie bylo zlamanie praw autorskich
to czy moglbys mi przeslac moze ten artykul ???

w jakim jezyku pisales ten dodatkowy modul ??

Tomek




Andrzej Kmicic - 11-11-2005 11:35

  > wogle caly projekt jest taki, ze niektore jego fragmenty najlepiej
> napisac w np JAVA (szybsze kodowanie) a inne musza byc bardzo
> szybkie i tu juz raczej C zostaje
>

Rozważania na temat szybkości w językach wyższego poziomu to dyskusja o
"wyższości świąt bożego narodzenia nad świętami wielkiej nocy" :). W
dzisiejszych czasach wszystkie języki wyższego poziomu mają ten parametr mniej
więcej wyrównany.
Do szybkich dużych obliczeń (rzeczywiście są dużo szybsze niż w PHP). Ja stosuję
Delphi a komunikację z PHP zapewnia mi wrapper Delphi4PHP napisany przez
Siergieja Przewożnika transponowany przez niego z Zend API w jezyku C. Tak że
myśę że napewno znajdziesz w sieci odpowiednie dla siebie moduły. Myslę że
żródła powinieneś znależć w serwisie Zend. Jeżeli używasz Delphi to polecam
właśnie Delphi4PHP, oprócz wrappera ze żródłami zawiera komponenty VCL, również
do pisania własnych rozszerzeń (dll). Nie wiem jak to jest z danymi czy przesył
dużych paczek danych jest równie szybki ale skomplikowane duże oblczenia są
ZDECYDOWANIE szybsze.
W układzie tym piszesz w języku wyższego poziomu bibliotekę dll i dokładasz ją
do istniejących rozszerzeń PHP, dopisujesz ją do rozszerzeń w PHP.INI i
korzystasz do woli !!!. Powodzenia.

pozdrawiam
Andrzej Kmicic




tomm - 11-11-2005 11:35

  > właśnie Delphi4PHP, oprócz wrappera ze żródłami zawiera komponenty VCL,
> również do pisania własnych rozszerzeń (dll). Nie wiem jak to jest z
> danymi czy przesył dużych paczek danych jest równie szybki ale
> skomplikowane duże oblczenia są ZDECYDOWANIE szybsze.

dzieki za odpowiedz,
niestety Delphi i dll odpada, musi chodzic na unix

pozdrawiam,

Tomek




Marcin Staniszczak - 11-11-2005 11:35

  tomm wrote:

> dzieki wielkie,
> jesli by to nie bylo zlamanie praw autorskich
> to czy moglbys mi przeslac moze ten artykul ???
>
> w jakim jezyku pisales ten dodatkowy modul ??
>
>

Szczerze mówiąc nie bardzo mogę:-(
Moduł pisany był w czystym C - testowany pod Linux-em.
Ale jako że to tylko artykuł w gazecie to można to potraktować jako
swojego rodzaju wprowadzenie. Następnie polecam analizę modułów
dołączonych do PHP-a.

Pozdrawiam,
Marcin Staniszczak




Andrzej Kmicic - 11-11-2005 11:35

  >
> dzieki za odpowiedz,
> niestety Delphi i dll odpada, musi chodzic na unix
>

To pozostaje C ... i Zend_Api
--
Andrzej Kmicic




Tomator - 11-11-2005 11:36

  Użytkownik "tomm" :

> niestety Delphi i dll odpada, musi chodzic na unix

Wtedy Delphi zmienia nazwę na Kylix, a odpadają biblioteki VCL.




Marcin Wasilewski - 11-11-2005 11:37

 
Użytkownik "tomm" <tmroz1@poczta.gazeta.pl> napisał w wiadomości
news:dki6bt$4op$1@inews.gazeta.pl...

[..]

A obsługa sesji Ci nie starczy? Php oferuje obsługę sesji poprzez własne
funkcje użytkownika. Jeśli zależy Ci na szybkości, to jako katalog ze
zmiennmi sesyjnymi możesz wskazać np. jakąś partycje wirtualną w RAM.
Zresztą o ile dobrze pamiętam, to PHP ma możliwość przechowywania zmiennych
sesyjnych w pamięci, zamiast w plikach.




tomm - 11-11-2005 11:37

 
> A obsługa sesji Ci nie starczy? Php oferuje obsługę sesji poprzez własne
> funkcje użytkownika. Jeśli zależy Ci na szybkości, to jako katalog ze
> zmiennmi sesyjnymi możesz wskazać np. jakąś partycje wirtualną w RAM.
> Zresztą o ile dobrze pamiętam, to PHP ma możliwość przechowywania
> zmiennych sesyjnych w pamięci, zamiast w plikach.

wiem, dla mnie natomiast idelna sytuacja bylo by taka,
ze mialbym po stronie serwera przez caly czas istniejace jakies obiekty,
te obiekty mogly by byc nie zwiazane z sesja

Tomek




Taki Jeden - 11-11-2005 11:37

  Andrzej Kmicic wrote:

>> wogle caly projekt jest taki, ze niektore jego fragmenty najlepiej
>> napisac w np JAVA (szybsze kodowanie) a inne musza byc bardzo
>> szybkie i tu juz raczej C zostaje
>>
>
> Rozważania na temat szybkości w językach wyższego poziomu to dyskusja o
> "wyższości świąt bożego narodzenia nad świętami wielkiej nocy" :). W
> dzisiejszych czasach wszystkie języki wyższego poziomu mają ten parametr
> mniej więcej wyrównany.

Który parametr, i co to znaczy "mniej więcej"?

Patrz: http://shootout.alioth.debian.org/

Bartek

> Do szybkich dużych obliczeń (rzeczywiście są dużo szybsze niż w PHP). Ja
> stosuję Delphi a komunikację z PHP zapewnia mi wrapper Delphi4PHP napisany
> przez Siergieja Przewożnika transponowany przez niego z Zend API w jezyku
> C. Tak że myśę że napewno znajdziesz w sieci odpowiednie dla siebie
> moduły. Myslę że żródła powinieneś znależć w serwisie Zend. Jeżeli używasz
> Delphi to polecam właśnie Delphi4PHP, oprócz wrappera ze żródłami zawiera
> komponenty VCL, również do pisania własnych rozszerzeń (dll). Nie wiem jak
> to jest z danymi czy przesył dużych paczek danych jest równie szybki ale
> skomplikowane duże oblczenia są ZDECYDOWANIE szybsze.
> W układzie tym piszesz w języku wyższego poziomu bibliotekę dll i
> dokładasz ją do istniejących rozszerzeń PHP, dopisujesz ją do rozszerzeń w
> PHP.INI i korzystasz do woli !!!. Powodzenia.
>
> pozdrawiam
> Andrzej Kmicic

--
"Kobiety nigdy nie wybaczają mężczyznom błędów, które popełniły"
(Henryk Sienkiewicz)




Taki Jeden - 11-11-2005 11:37

  tomm wrote:

> Witam,
>
> problem jest taki, na serwerze (mowa o PHP) powinny
> byc przez caly czas przechowywane pewne obiekty,
> nie tylko na czas wykonywania skryptu,
> nie chodzi mi tez o ich zapamietywanie poprzez serializacje,

Ja chyba nie bardzo rozumiem - jeśli nie chcesz ich serializować, to w jaki
sposób chcesz je zapamiętać gdziekolwiek?

> to musi byc bardzo bardzo szybkie
>
> dlatego pomyslalem o napisaniu wlasnego modulu do PHP,
>
> teraz pytania:
> 1. czy jesli napisze taki modul, moze on sobie zyc wlasnym zyciem,
> a jednoczesnie np. dostarczac jakis danych do skryptow
>
> musi bowiem to byc w pelni dzialajacy jakby osobny program
> przechowujacy dane w sobie, komunikujacy sie z baza itp
>
> 2. czy ma ktos z was praktyke w pisaniu takich modulow
>
> 3. moze jest inne rozwiazanie tego problemu, moze nie modul a jakos
> inaczej
> ogolnie chodzi wlasnie o osobny program ale posiadajacy bardzo szybkie
> i wydajne polaczenie z skryptami PHP (komunikacja np. poprzez plik,
> czy baze odpada)
>
> bede bardzo wdzieczny za wszelkie podpowiedzi
>
> pozdrawiam,
>
> Tomek

--
"Kobiety nigdy nie wybaczają mężczyznom błędów, które popełniły"
(Henryk Sienkiewicz)




tomm - 11-11-2005 11:37

  > Ja chyba nie bardzo rozumiem - jeśli nie chcesz ich serializować, to w
> jaki
> sposób chcesz je zapamiętać gdziekolwiek?

tak jak na serwerach aplikacji na JAVA, miec jakies obiekty
pod spodem, obiekty maja sobie zyc przez caly czas,
a nawet cos tam robic, niezaleznie od wywolan skrypow

taki zyjacy sobie serwer, mogacy robic rozne rzeczy,
a dodatkowo wystawiac stronki, skrypty stronek
mialby jednak dostep do tego co na serwerze
i to nie ma byc jaks posrednia warstwa ale posrednio

Tomek




Taki Jeden - 11-11-2005 11:37

  tomm wrote:

>> Ja chyba nie bardzo rozumiem - jeśli nie chcesz ich serializować, to w
>> jaki
>> sposób chcesz je zapamiętać gdziekolwiek?
>
> tak jak na serwerach aplikacji na JAVA, miec jakies obiekty
> pod spodem, obiekty maja sobie zyc przez caly czas,
> a nawet cos tam robic, niezaleznie od wywolan skrypow
>
> taki zyjacy sobie serwer, mogacy robic rozne rzeczy,
> a dodatkowo wystawiac stronki, skrypty stronek
> mialby jednak dostep do tego co na serwerze
> i to nie ma byc jaks posrednia warstwa ale posrednio

Tyle to ja rozumiem, wątpliwość mam innej natury. IMHO jest tak (jeśli się
mylę to niech mnie ktoś poprawi):

To o czym piszesz to nie jest wynalazek Javy, tak samo jest w wielu innych
serwerach napisanych w różnych językach. Tylko że w przypadku php obsługą
requestów zajmuje się demon httpd, który w razie potrzeby korzysta z
interpretera php. Więc jeżeli chcesz przechowywać gdzieś referencje do
obiektów utworzonych przez php, to nie bardzo jest gdzie, bo nie ma czegoś
takiego jak demon php. Chyba że zająłby się tym główny proces/wątek httpd,
ale to by już wymagało przerobienia Apacza.

Natomiast bez problemy dałoby się napisać program który będzie chodził cały
czas, przechowywał 'persistent data' i udostępniał je skryptom php na
życzenie, a także robił wiele innych interesujących rzeczy. Ale on musi się
jakoś z tymi pehapami komunikować, i czy to będzie XMLRPC, czy CORBA, czy
pipe'y, czy shared memory, czy cokolwiek, to obiekt żeby wysłać trzeba
zserializować, innej możliwości nie widzę. Chyba że napiszesz w C funkcje
do PHP umożliwiające zapisanie danych z obszaru pamięci zajmowanego przez
obiekt, a potem utworzenie obiektu z tych danych, czyli alokowanie obszaru
pamięci i zapisanie w nim tych danych. Może to jest możliwe, a może nie.

Bartek

>
> Tomek

--
"Kobiety nigdy nie wybaczają mężczyznom błędów, które popełniły"
(Henryk Sienkiewicz)




porneL - 11-11-2005 11:37

  On Wed, 09 Nov 2005 11:46:48 -0000, Taki Jeden <bartekgorny@interia.pl>
wrote:

>
> Natomiast bez problemy dałoby się napisać program który będzie chodził
> cały
> czas, przechowywał 'persistent data' i udostępniał je skryptom php na
> życzenie, a także robił wiele innych interesujących rzeczy. Ale on musi
> się
> jakoś z tymi pehapami komunikować, i czy to będzie XMLRPC, czy CORBA, czy
> pipe'y, czy shared memory, czy cokolwiek, to obiekt żeby wysłać trzeba
> zserializować, innej możliwości nie widzę. Chyba że napiszesz w C funkcje
> do PHP umożliwiające zapisanie danych z obszaru pamięci zajmowanego przez
> obiekt, a potem utworzenie obiektu z tych danych, czyli alokowanie
> obszaru
> pamięci i zapisanie w nim tych danych. Może to jest możliwe, a może nie.

To już napisano. http://php.net/shmop

--
* html {redirect-to: url(http://browsehappy.pl);}
this.author = new Geek("porneL");




Artur Muszynski - 11-11-2005 11:37

  >> Rozważania na temat szybkości w językach wyższego poziomu to dyskusja o
>> "wyższości świąt bożego narodzenia nad świętami wielkiej nocy" :). W
>> dzisiejszych czasach wszystkie języki wyższego poziomu mają ten parametr
>> mniej więcej wyrównany.
>
> Który parametr, i co to znaczy "mniej więcej"?
>
> Patrz: http://shootout.alioth.debian.org/

"How can we benchmark language implementations?
We can't - we measure particular programs."

.... co IMHO daje tak samo bzdurne wyniki. Swego czasu jakaś firma
specjalizująca się w benchmarkowaniu przeniosła dużą aplikację bazodanową z
Javy na C# i okazało się, że wyniki są co najmniej kontrowersyjne, bo inny
był serwer bazy danych (SQL Server, Oracle), inne funkcje biblioteczne itd.

Przeciwny jestem pakowaniu do wspólnego worka wszystkich języków, bo C i PHP
są jednak bardzo daleko od siebie. Większości opytmalizacji normalnych dla C
nie wykona się dla PHP. Przy dużych projektach znacznie ważniejsza jest
jednak optymalizacja na poziomie algorytmów i metod niż na poziomie kodu.

artur

>
> Bartek




porneL - 11-11-2005 11:37

  On Wed, 09 Nov 2005 14:00:15 -0000, Artur Muszynski
<arturm@union.wytnijto.com.pl> wrote:

> ... co IMHO daje tak samo bzdurne wyniki. Swego czasu jaka? firma
> specjalizuj?ca si? w benchmarkowaniu przenios?a du?? aplikacj?
> bazodanow? z
> Javy na C# i okaza?o si?, ?e wyniki s? co najmniej kontrowersyjne, bo
> inny
> by? serwer bazy danych (SQL Server, Oracle), inne funkcje biblioteczne
> itd.
>
> Przeciwny jestem pakowaniu do wspólnego worka wszystkich j?zyków, bo C i
> PHP
> s? jednak bardzo daleko od siebie. Wi?kszo?ci opytmalizacji normalnych
> dla C
> nie wykona si? dla PHP. Przy du?ych projektach znacznie wa?niejsza jest
> jednak optymalizacja na poziomie algorytmów i metod ni? na poziomie kodu.

Co więcej w przypadku języków liczy się też wydajność programisty. Co z
tego, że mógłbym przepisać swoją PHPową aplikację w assemblerze, jeśli by
mi to zajęło pare ładnych miesięcy? Za koszt mojej pracy można by kupić
bardziej wypasiony serwer albo jakimś acceleratorem/cache uzyskać 80%
efektu w 15 minut.

--
* html {redirect-to: url(http://browsehappy.pl);}
this.author = new Geek("porneL");




tomm - 11-11-2005 11:37

 
> To już napisano. http://php.net/shmop

tylko jak teraz szybko wymieniac dane pomiedzy
PHP a np JAVA, lub C++, bez serailizacji
do np. XML sie nie obejdzie, a to jest kosztowne

Tomek




Marcin Staniszczak - 11-11-2005 11:37

  tomm wrote:
>>To już napisano. http://php.net/shmop
>
>
> tylko jak teraz szybko wymieniac dane pomiedzy
> PHP a np JAVA, lub C++, bez serailizacji
> do np. XML sie nie obejdzie, a to jest kosztowne
>

Np. http://pl.php.net/manual/en/ref.java.php. Wsparcie dla komunikacji z
Java zapewnia także Zend Platform, ale to kosztuje. Zawsze można też np.
sockety;-)

Pozdrawiam
Marcin Staniszczak




Taki Jeden - 11-11-2005 11:37

  porneL wrote:

> On Wed, 09 Nov 2005 11:46:48 -0000, Taki Jeden <bartekgorny@interia.pl>
> wrote:
>
>>
>> Natomiast bez problemy dałoby się napisać program który będzie chodził
>> cały
>> czas, przechowywał 'persistent data' i udostępniał je skryptom php na
>> życzenie, a także robił wiele innych interesujących rzeczy. Ale on musi
>> się
>> jakoś z tymi pehapami komunikować, i czy to będzie XMLRPC, czy CORBA, czy
>> pipe'y, czy shared memory, czy cokolwiek, to obiekt żeby wysłać trzeba
>> zserializować, innej możliwości nie widzę. Chyba że napiszesz w C funkcje
>> do PHP umożliwiające zapisanie danych z obszaru pamięci zajmowanego przez
>> obiekt, a potem utworzenie obiektu z tych danych, czyli alokowanie
>> obszaru
>> pamięci i zapisanie w nim tych danych. Może to jest możliwe, a może nie.
>
> To już napisano. http://php.net/shmop

shmop umożliwia zapisanie ciągu znaków w pamięci dzielonej. Ciągu znaków, na
przykład zserializowanego obiektu. A chodzi o to żeby uniknąć serializacji.

--
"Kobiety nigdy nie wybaczają mężczyznom błędów, które popełniły"
(Henryk Sienkiewicz)




Taki Jeden - 11-11-2005 11:37

  Artur Muszynski wrote:

>>> Rozważania na temat szybkości w językach wyższego poziomu to dyskusja o
>>> "wyższości świąt bożego narodzenia nad świętami wielkiej nocy" :). W
>>> dzisiejszych czasach wszystkie języki wyższego poziomu mają ten parametr
>>> mniej więcej wyrównany.
>>
>> Który parametr, i co to znaczy "mniej więcej"?
>>
>> Patrz: http://shootout.alioth.debian.org/
>
> "How can we benchmark language implementations?
> We can't - we measure particular programs."
>
> ... co IMHO daje tak samo bzdurne wyniki.

W takim razie który parametr jest twoim zdaniem wyrównany, i jak to
sprawdziłeś?

Wyniki nie są tak do końca bzdurne, bo jeśli wykonanie jakiejś, dość
precyzyjnie określonej, operacji trwa w jednym języku 2s a w drugim na
przykład 140s, to jednak o czymś świadczy. A wyniki są często zgodne z
przewidywaniami, np w obsłudze drzew binarnych LISP bije nawet C.

B.

> Swego czasu jakaś firma
> specjalizująca się w benchmarkowaniu przeniosła dużą aplikację bazodanową
> z Javy na C# i okazało się, że wyniki są co najmniej kontrowersyjne, bo
> inny był serwer bazy danych (SQL Server, Oracle), inne funkcje
> biblioteczne itd.
>
> Przeciwny jestem pakowaniu do wspólnego worka wszystkich języków, bo C i
> PHP są jednak bardzo daleko od siebie. Większości opytmalizacji normalnych
> dla C nie wykona się dla PHP. Przy dużych projektach znacznie ważniejsza
> jest jednak optymalizacja na poziomie algorytmów i metod niż na poziomie
> kodu.
>
>
>
> artur
>
>
>
>
>>
>> Bartek

--
"Kobiety nigdy nie wybaczają mężczyznom błędów, które popełniły"
(Henryk Sienkiewicz)




porneL - 11-11-2005 11:37

  On Wed, 09 Nov 2005 16:09:47 -0000, Taki Jeden <bartekgorny@interia.pl>
wrote:

> W takim razie który parametr jest twoim zdaniem wyrównany, i jak to
> sprawdziłeś?
>
> Wyniki nie są tak do końca bzdurne, bo jeśli wykonanie jakiejś, dość
> precyzyjnie określonej, operacji trwa w jednym języku 2s a w drugim na
> przykład 140s, to jednak o czymś świadczy. A wyniki są często zgodne z
> przewidywaniami, np w obsłudze drzew binarnych LISP bije nawet C.

Nie, właśnie niewiele to świadczy. np. do znalezienia unikalnych stringów
w C bym pisał drzewo binarne, ale w PHP nie muszę - wystarczy użyć kluczy
tablic i będzie to kilkadziesiąt razy szybsze, niż własna implementacja
drzewa w PHP.

Oczywiście nie przeczę, że jeden jest szybszy od drugiego, ale na
podstawie takich benchmarków nie można stwierdzić, że język X jest lepszy
od języka Y.

--
* html {redirect-to: url(http://browsehappy.pl);}
this.author = new Geek("porneL");




porneL - 11-11-2005 11:37

  On Wed, 09 Nov 2005 15:58:44 -0000, Taki Jeden <bartekgorny@interia.pl>
wrote:

>> To już napisano. http://php.net/shmop
>
> shmop umożliwia zapisanie ciągu znaków w pamięci dzielonej. Ciągu
> znaków, na
> przykład zserializowanego obiektu. A chodzi o to żeby uniknąć
> serializacji.

Jeśli PHP i ten drugi język nie używają binarnie kompatybilnych struktur
(co jest bardzo mało prawdopodobne), to nie unikniesz
serializacji/konwersji.

W najlepszym przypadku można napisać moduł PHP, który przez jego API
będzie udostępniał odczyt/zapis obiektów z zewnątrz, ale zależnie od
ilości dostępów może to się okazać wolniejsze niż
serializacja+deserializacja.

--
* html {redirect-to: url(http://browsehappy.pl);}
this.author = new Geek("porneL");
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    [mysql/php] jak =?ISO-8859-2?Q?zliczy=E6_ilo=B6=E6_unikalnyc?==?ISO-8859-2?Q?h_rekord=F3w_w_jednym_zapytaniu=3F?= Delphi for PHP Borlanda - co =?ISO-8859-2?Q?s=B1dzicie_o_tym?==?ISO-8859-2?Q?_pakiecie=3F?= [PHP i MySQL] Wstawianie =?ISO-8859-2?Q?rekord=F3w_do_bazy_?==?ISO-8859-2?Q?a_z=B3e_kodowanie?= mysql+php - =?ISO-8859-2?Q?wydajno=B6=E6_przy_olbrzymiej_i?==?ISO-8859-2?Q?lo=B6ci_rekord=F3w?= [MySQL] - Wstawianie aktualnej daty do bazy danych - PHP i MySQL Jedno zapytanie różne wyniki w polu data [mysql i mysql+php] [MySQL/PHP] Wyszukiwanie rekordu przez kolumnę wskazaną przez zmienną [Praca - Warszawa] Programista aplikacji internetowych, PHP, AJAX, CSS Rozwijany tekst jak z http://www.punters.pl/typy.php [PHP] wysylanie pliku na serwer, a inkrementacja nazwy plikow
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • marcelq.xlx.pl
  • Cytat

    Decede mihi sole - nie zasłaniaj mi słonca.
    Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
    Hoc fac - tak czyń.
    A tergo - od tyłu; z tyłu.
    I czarne włosy posiwieją. Safona

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com