Scripteditor met function-splitter & PHP performance

[Knakker]

1. Pak en beet 9 jaar terug zat bij QBASIC een editor waarmee Subs en Functions in je script makkelijk toegankelijk waren via een speciaal menu.

Als ik met een website bezig ben dan werk ik meestal met een apart include bestand dat alle schermweergave regelt; anders staat mijn code tussen alle HTML brei en dat maakt het niet overzichtelijker. Echter op een gegeven moment wordt zo'n include bestand makkelijk 100 kB (een heel administratiekantoor waarin je alle aspecten van een website kunt veranderen), en dan kost even een functie opzoeken - zelfs als je structureel alles goed hebt geordend - best wel veel tijd. Het zou ideaal zijn als er voor de 'moderne' scripttalen een dergelijke editor bestond als die destijds bij QBASIC zat.


2. Hoe gaat PHP met zo'n 100 kB include-bestand om? Ik zal ff uiteenzetten hoe een script bij mij bijvoorbeeld werkt:

- Aangeroepen wordt bijvoorbeeld admin.php?actie=admin_toon_wijzig_gegevens&verdereshit

- In admin.php staat bijna bovenaan: include("admin.inc.php"); admin.inc.php bestaat uit heeeeeel veel functions die alle mogelijke HTML brei op het scherm toveren.

- Na verscheidene if-clauses (heb je wel admin-rechten, dat soort crap) komt er dan uiteindelijk een call naar de desbetreffende functie in admin.inc.php en het relevante wordt getoond.

Wat ik mij nu dus afvraag: heeft het feit dat dit include bestand zo gigantisch groot is een impact op de performance of niet? Ik draai zelf een webserver op mijn P4 2400 Mhz met 1 Gb RAM, dus voor mij verschijnen de pagina's instantly. Echter als deze website op een server komt te draaien die niet zo snel is (bijv. omdat ie gedeeld is met allemaal andere sites) én er zijn een tiental bezoekers die tegelijkertijd een pagina opvragen, heeft het dan zin om zo'n groot include bestand op te splitsen in kleinere stukjes? Of kan ik beter een andere (efficientere) werkwijze gebruiken?

Alvast bedankt.

[ACM]

Het opsplitsen heeft alleen zin als je niet dan alle opgesplitste delen nodig hebt.

Opsplitsen omdat de boel dan makkelijker te beheren/maken is, is een andere reden om op te splitsen trouwens. Maar ik denk niet dat je veel performance verschil zal zien daarmee.

Als je dus zo kan splitsen dat er bepaalde (grote) delen alleen maar af en toe geinclude worden, dan heeft het nut, anders niet (voor de performance)

[beany]

Knakker schreef op 06 December 2002 @ 15:17:
1. Pak en beet 9 jaar terug zat bij QBASIC een editor waarmee Subs en Functions in je script makkelijk toegankelijk waren via een speciaal menu.

Zend heeft een editor voor PHP, maar die kost geloof ik geld. En als dit ding geen geld kost is het probleem dat dat kreng in java is geschreven. Verder weet ik geen editor met de functionaliteiten die jij zoekt voor PHP.

2. Hoe gaat PHP met zo'n 100 kB include-bestand om? Ik zal ff uiteenzetten hoe een script bij mij bijvoorbeeld werkt:

<knip>

Wat ik mij nu dus afvraag: heeft het feit dat dit include bestand zo gigantisch groot is een impact op de performance of niet? Ik draai zelf een webserver op mijn P4 2400 Mhz met 1 Gb RAM, dus voor mij verschijnen de pagina's instantly. Echter als deze website op een server komt te draaien die niet zo snel is (bijv. omdat ie gedeeld is met allemaal andere sites) én er zijn een tiental bezoekers die tegelijkertijd een pagina opvragen, heeft het dan zin om zo'n groot include bestand op te splitsen in kleinere stukjes? Of kan ik beter een andere (efficientere) werkwijze gebruiken?

Alvast bedankt.

Een include file van 100kb is niet zo'n probleem... voor 1 user! Als er 100 man zit te surfen wordt het wat moeilijker. Is 100kb niet wat veel voor 1 pagina? Probeer het wat te splitsen in meerdere include files, en bekijk runtime welke groepen functies je nodig hebt en include die dan.

Je moet vooral niet kijken hoe 'snel ie is' met 1 enkele user. Probeer je web-app eens te stress testen(hier zijn proggies voor) en laat er een gebruiker of 25 a 100 tegelijkertijd op werken.

[ACM]

beany schreef op 06 december 2002 @ 15:23:
Een include file van 100kb is niet zo'n probleem... voor 1 user! Als er 100 man zit te surfen wordt het wat moeilijker. Is 100kb niet wat veel voor 1 pagina? Probeer het wat te splitsen in meerdere include files, en bekijk runtime welke groepen functies je nodig hebt en include die dan.

Je moet vooral niet kijken hoe 'snel ie is' met 1 enkele user. Probeer je web-app eens te stress testen(hier zijn proggies voor) en laat er een gebruiker of 25 a 100 tegelijkertijd op werken.

't includen gaat doorgaans erg snel, tenzij het allemaal classes zijn, dus de kans is groot dat je "winst" door minder te includen verloren gaat door de kosten van het "intelligenter includen". Maar daar kom je alleen achter als je het gaat testen

[Knakker]

Nee, die 100 kB is niet voor 1 pagina - sorry, dat was niet duidelijk. In dat bestand van 100 kB zitten zeg maar 20-30 schermen (klantgegevens, bestellinggegevens, produktbeheer, interne communicatie, e-mailen, etc). Je begrijpt dus dat van die 20-30 functies er hooguit 2 of 3 per pagina-aanroep nodig zijn.

Waar het meer om gaat: als PHP een bestand voor z'n neus krijgt met 30 functies daarin - gaat ie dan eerst alle 30 functies parsen (of wat ie er maar mee doet) of scant ie er vlug overheen en voert ie alleen díe functies uit die gevraagd worden?

[ACM]

Hij test niet of elke functie helemaal correct is, maar er wordt wel wat parsing gedaan over je file.

Als je dus nu alle schermen van alle pagina's samengevoegd hebt dan is het ook makkelijk te splitsen lijkt me?
In dat geval zou ik er es naar kijken hoeveel tijdsverschil er is tussen:

code:

include('totaal.schermen.php');

en

code:

include('scherm_van_deze_pagina.php');

En dan natuurlijk met een functie als microtime de tijd vergelijken.

[Knakker]

Ja, het is heel makkelijk te splitsen. Ik heb alles meer bij elkaar gegooid omdat ik niet zo'n fan ben van 10 losse bestanden. En als je zo'n editor hebt met makkelijke functietoegang dan prefereer ik dat boven allemaal losse bestanden.

Maar ik heb uit een include bestand van 56 kB ff een gedeelde schermen m.b.t. produktbeheer van 19 kB gelicht en apart opgeslagen en het verschil is gewoon lineair:

include("admin.inc.php") kostte 0.006523 seconden
include("admin.produkten.inc.php") kostte 0.002244 seconden

In beginsel is het dus zeker het verschil waard. Of ik het nou nog ga splitsen (omdat het om hooguit een mens of 5 tegelijkertijd per seconde zal gaan) weet ik nog niet.


Heb je misschien ook een antwoord op mijn 1e vraag?

[-RenE-]

Waarom gebruik je niet een folding editor. Vim kan dat, maar als je wat minder spartaans wilt kun je eens kijken naar Jedit. Standaard kun je dan instellen dat alles "ingeklapt" is en alleen de functienaam zichtbaar.

Jedit kost niks en draait op alle platformen onder Java. Kijk ook even naar de goed plugins (CVS, ftp etc). Wil je commercieel (en duur) dan is Visual Slickedit wellicht wat voor je.

[chem]

kijk eens naar ultraedit(.com) als eerste. Die gebruik ik @ windows, en ten volle tevredenheid. Er zit een functionlist in, en een folding-geval.

[stekkel]

www.scintilla.org

is een hele leuke link for een zeer goede editor met folding mogelijkheden.

[Knakker]

Ultra-Edit bevalt me prima ^O^ ... maar hoe krijg ik die irritante gele achtergrond weg (de actieve regel wordt geel gekleurd)? Kan het nergens vinden...

[chem]

staat 'ergens' in je configuration... loop alles na, het kan wel meen ik.
btw, voor PHP heb ik nog wel een getweakte wordfile.txt, die ook cases oppikt en classes.

het is altijd raadzaam bij UE elke maand ff door de config te lopen er kan teveel om dat te onthouden en te bedenken of het nuttig is.

[pjonk]

Hmm vind dat zelf juist een erg handige feature.
Maar in het menu View|Set colors kan je dit eventueel uitzetten.

edit:
De optie die je zoekt is Enable Active Line coloring

[ Voor 23% gewijzigd door pjonk op 07-12-2002 16:30 ]

[Knakker]

Ah, bedankt! Ik vind dat verschrikkelijk irritant, kan er niks aan doen

chem, zou je je aangepaste wordfile.txt kunnen mailen naar mij? [e-mail] - bedankt!

[Sn3akz]

beany schreef op 06 December 2002 @ 15:23:
*knip*

Probeer je web-app eens te stress testen(hier zijn proggies voor) en laat er een gebruiker of 25 a 100 tegelijkertijd op werken.

Kan je een paar links geven? Ik wil best zoeken.. maar als je er toevallig een paar weet

[chem]

Knakker schreef op 07 December 2002 @ 16:39:
Ah, bedankt! Ik vind dat verschrikkelijk irritant, kan er niks aan doen

chem, zou je je aangepaste wordfile.txt kunnen mailen naar mij? [e-mail] - bedankt!

ik zal hem maandag online zetten als ik er aan denk.

[chem]

http://www.parse.nl/~michiel/WORDFILE.TXT

vooral:

code:

/Delimiters = ~!@%^&*()+=|\{}[]:;"'<> , .?
/Function String = "%^([^t ]++function[^t ]+[a-zA-Z0-9_&]+*^)^p"
/Function String 1 = "%[^t ]++^(class[^t ]+[a-zA-Z0-9_&]+*^)^p"
/Function String 2 = "^(%[^t ]++case[^t ]+'*'^)[^t ]++:[^p^t ]++"
/Function String 3 = "^(%[^t ]++switch[^t ]++(*)^)[^p^t ]++"

en nog 2 /c's toegevoegd.

[ Voor 82% gewijzigd door chem op 09-12-2002 15:10 ]