Speed ​​variasjoner - Prosedyre vs. OO i tolket språk

stemmer
18

I tolket programmeringsspråk som PHP og Javascript, hva er konsekvenser av å gå med et objektorientert tilnærming over et prosedyre tilnærming?

Spesielt det jeg leter etter er en sjekkliste over ting du bør vurdere når du oppretter en web-applikasjon og velge mellom prosessuelle og Objektorientert tilnærminger, for å optimalisere ikke bare for fart, men vedlikeholds også. Sitert forskning og test tilfeller ville være nyttig også hvis du vet om noen av artiklene utforske dette videre.

Bottom line: hvor stor (hvis noen) er forestillingen treffer egentlig, når du går med OO vs. prosedyre i et tolket språk?

Publisert på 06/08/2008 klokken 03:34
kilden bruker
På andre språk...                            


7 svar

stemmer
17

Kanskje jeg er gal, men bekymringsfull om fart i tilfeller som dette ved hjelp av en fortolkende språk er som å prøve å finne ut hvilken farge å male skjulet. La oss ikke engang komme inn i ideen om at denne typen optimalisering er helt pre-moden.

Du treffer spikeren på hodet når du sa 'vedlikehold'. Jeg vil velge den tilnærming som er den mest produktive og mest vedlikeholds. Hvis du trenger fart senere, er det ikke skal komme fra veksling mellom prosedyre versus objektorientert koding paradigmer innenfor et tolket språk.

Svarte 06/08/2008 kl. 03:36
kilden bruker

stemmer
10

Dessverre, jeg har gjort mine tester også. Jeg gjorde test fart, og det er omtrent det samme, men ved testing for minnebruk får memory_get_usage () i PHP, så jeg en overveldende større antall på OOP side.

116,576 byte for OOP til 18,856 byte for prosedyre. Jeg vet "Hardware er billig", men kom igjen! 1000% økning i bruk? Beklager, det er ikke optimal. Og å ha så mange brukere treffer ditt nettsted på en gang, er jeg sikker på RAM ville bare brenne, eller kjøre ut. Er jeg galt?

Svarte 22/07/2011 kl. 21:28
kilden bruker

stemmer
5

Kort sagt: nei, fordi den overliggende av tolkningen overvelder overhead av metoden sending.

Svarte 06/08/2008 kl. 03:35
kilden bruker

stemmer
2

Hvis du bruker et tolket språk, forskjellen er irrelevant. Du bør ikke bruke et tolket språk om ytelsen er et problem. Begge vil utføre omtrent det samme.

Svarte 06/08/2008 kl. 03:49
kilden bruker

stemmer
1

I min erfaring, vil et område med stor belastning bli sugd ned og slutte å svare mye lettere med OOP kode enn prosessuelle. Årsaken er lett å forstå.

OOP krever mye mer minnetildelinger (malloc) og mange flere operasjoner for å kjøre i minnet enn prosedyrekode. Det krever mye mer CPU tid til å utføre sine oppgaver. Det er så godt som 'overhead', pakket rundt prosedyrekode, og legger til CPU byrde å gjennomføre det, spesielt når du utfører databaseoperasjoner.

Mange programmerere som bekvemmeligheten av OOP, skape små svarte bokser gjemt bak enkle grensesnitt. Men jeg har blitt betalt godt for å gjenopplive områder som ble tatt for alltid å svare under tung bruker belastning. Stripping ut OOP og erstatte den med enkle saksbehandlingsfunksjoner gjort en stor forskjell.

Hvis du ikke forventer at nettstedet skal være veldig opptatt, for all del bruke OOP. Hvis du bygger en høy trafikk system, vil du ønsker å stripe hver CPU syklus fra behandlingen og hver byte fra produksjonen som du kan.

Svarte 22/03/2015 kl. 19:31
kilden bruker

stemmer
1

Dine resultater vil bli preget av gjennomføring, ikke språket. Du kan bruke den tregeste språket og det kan skalere til å være den største nettstedet i verden, så lenge du designe det å skalere.

Bare husk den første regelen for optimiztion.

Ikke.

:)

Svarte 22/09/2008 kl. 18:18
kilden bruker

stemmer
0

Jeg har faktisk gjort en liten test som dette i python på en nettside jeg vedlikeholde og funnet ut at de er nesten tilsvarende i fart, med prosessuelle tilnærmingen vinne med noe sånt som ti-tusendels sekund, men at OO koden var så betydelig renere jeg ikke fortsette øvelsen lenger enn en gjentakelse.

Så egentlig, spiller det ingen rolle (i min erfaring allikevel).

Svarte 26/08/2008 kl. 20:01
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more