php5 vs. asp.net

Tags:    php

<< < 123 > >>
Vær hilset!
Jeg kender selv noget til begge sprog, men har undertiden en smule svært ved at vurdere, om php5 kan konkurrere med asp.net mht. hastighed, loading af sider osv.. Jeg har søgt en del på nettet, men har svært ved at finde noget fra en pålidelig kilde. Derfor henvender spørgsmålet, om hvorvidt php5 er hurtigere eller i det hele taget bedre end asp.net, sig til folk, som ved noget om det. Altså ville en objektiv, underbygget vurdering være dejlig : )



Indlæg senest redigeret d. 16.07.2006 15:28 af Bruger #10105
Tror du misforstod den Jonathan :). PHP virker internt ved at den tager scriptkoden og laver den om til en gang binær kode, som den herefter udfører. Der findes muligheder for cache-optimering, for eksempel Turck MM-cache, men som standard er det ikke tilfældet. Mere om hvordan PHP udfører tingene kan du finde her: http://trickie.org/code/zend_engine_one/index.html . Hvis det skal være kan jeg også godt finde dig nogle referencer i PHP's kildekode.



Tror du misforstod den Jonathan :). PHP virker internt ved at den tager scriptkoden og laver den om til en gang binær kode, som den herefter udfører. Der findes muligheder for cache-optimering, for eksempel Turck MM-cache, men som standard er det ikke tilfældet. Mere om hvordan PHP udfører tingene kan du finde her: http://trickie.org/code/zend_engine_one/index.html . Hvis det skal være kan jeg også godt finde dig nogle referencer i PHP's kildekode.


Jeg er lidt forvirret.

Hvad er fordelen i en cache som cacher bytekoden, hvis PHP allerede gør dette?

Og hvis ikke PHP cacher bytekoden, hvorfor så snakke om den i forbindelse med hastighed når PHP skal producere bytekoden hver eneste gang siden køres?

Så er det faktisk muligvis bare endnu mere overhead, i forhold til dengang PHP blot fortolkede scriptet ... set med performance briller altså.

?

Fint du nævner Turck MM-cache ... netop det som understreger min pointe.
Hvorfor bruge Turck MM-cache, hvis PHP allerede gør det samme? Zend's cache er ihvertfald kun promiller langsommere end Turck MM-cache.
Turck MM-cache cacher nemlig ikke output, men bytecode.



Fin artikel!

Jeg tror Zend røvrender PHP folkene ... for at kunne sælge sin accelerator.

Det burde være default at PHP cacher sin bytekode (Up Codes) sammen med timestamp for last modified for pågældende fil.

En ret simpel manøvre, og ret suspekt at de ikke gør det.



Tja, jeg har overvejet at lave et par små hacks til interpreteren så den automatisk ville gemme dens bytecode output, men har ikke fået mig taget sammen :). PHP's kildekode er et værre rod, så det er halvbøvlet at finde rundt i skidten, men jeg tror jeg vil få fixet noget sammen.



Tja, jeg har overvejet at lave et par små hacks til interpreteren så den automatisk ville gemme dens bytecode output, men har ikke fået mig taget sammen :). PHP's kildekode er et værre rod, så det er halvbøvlet at finde rundt i skidten, men jeg tror jeg vil få fixet noget sammen.


Som om.

Nå, men om ikke andet lyder det da som du indser at PHP's bytekode funktion ikke betyder noget mærkværdigt når bytekoden ikke caches, men bygges or hver eneste page request.

MAO betyder ikke en skid for performance.

Og så er det to simple kald der tager sig af bytekode delen ... skulle vel nok være til at finde og modificere ... selv hvis man skal lede i noget rod, ikke?

Måske er det bare for stor en mundfuld for dig :D



Naah, det er mere om lysten er der til at drive værket ;). PHP's zend_compiler/zend_execute funktioner er function-pointers, og derfor skal der laves et modul som kan loades ind i PHP kernen(Eller denne skal direkte ændres) og overskrive zend_compile_file og zend_execute. Et sandt mareridt at skulle sidde og bøvle med når man ikke lige har en Linux maskine stående og ikke har nogle ordenlige PHP compilere på Windows platformen(Nej, jeg er ikke i besiddelse af MSVC03). Koden i sig selv er ikke så frygtelig bøvlet, men kompilering og tests af koden er derimod.

Jeg tvivler dog på at det ville være optimalt at ændre på zend_execute og zend_compile_file direkte, da forskellige andre moduler sagtens kan finde på at ændre dem også.



<< < 123 > >>
t