Microoptimering

[Leif Neland]

Øv også.

Nu har jeg lige brugt nogle timer på at optimere et stykke kode, der så
ineffektivt ud.

Resultat:

Gammel: Tid: 0.007339954376220 sek. Size: 77720 B
Ny: Tid: 0.005964994430542 sek. Size: 121808 B

Morale: Check først, om det er et problem...

Leif

--
Husk kørelys bagpå, hvis din bilfabrikant har taget den idiotiske
beslutning at undlade det.

[Rune Jensen]

On 27 Jan., 02:22, Leif Neland <l...@neland.dk> wrote:

> Gammel: Tid: 0.007339954376220 sek. Size:  77720 B
> Ny:     Tid: 0.005964994430542 sek. Size: 121808 B
>
> Morale: Check først, om det er et problem...

77kb lyder nu allerede af meget. Må være over 1000 linjer?

Kunne man ikke brække det op i mindre stykker, og så bruge conditional
include?

Det burde vel også være nemmere at forstå koden, og ikke mindst teste
den, hvis den er grupperet efter funktion.

Jeg har f.eks. includes for initiering, globale funktioner, ting, som
skal ske før header sendes, og efter, metodespecifikke og
sidespecifikke funktioner.

Der er ikke conditional include i ASP (et af de få steder, jeg synes
PHP har fordel), men man kan fuske lidt alligevel.


MVH
Rune Jensen

[Leif Neland]

Rune Jensen sendte dette med sin computer:

> On 27 Jan., 02:22, Leif Neland <l...@neland.dk> wrote:
>
>> Gammel: Tid: 0.007339954376220 sek. Size:  77720 B
>> Ny:     Tid: 0.005964994430542 sek. Size: 121808 B
>>
>> Morale: Check først, om det er et problem...
>
> 77kb lyder nu allerede af meget. Må være over 1000 linjer?
>
> Kunne man ikke brække det op i mindre stykker, og så bruge conditional
> include?
>

Det er ikke kodestørrelse, det er ramforbrug.
memory_get_usage før og efter.

Koden er ikke uoverskuelig:

foreach($this->items_flat as $item)
{
$kattree[$item['ParentId']]['children'][$item['id']]=$item;

$kattree[$item['id']]=&$kattree[$item['ParentId']]['children'][$item['id']];
};

Jeg skal have konverteret en træstruktur i en database, hvor hver node
kun har en parent, til et træ i et array, hvor hver node har et array
med children.

[Rune Jensen]

On 27 Jan., 11:37, Rune Jensen <runeofdenm...@gmail.com> wrote:
> On 27 Jan., 02:22, Leif Neland <l...@neland.dk> wrote:
>
> > Gammel: Tid: 0.007339954376220 sek. Size:  77720 B
> > Ny:     Tid: 0.005964994430542 sek. Size: 121808 B
>
> > Morale: Check først, om det er et problem...
>
> 77kb lyder nu allerede af meget. Må være over 1000 linjer?

Nu bruger du sikkert en kodeeditor allerede, men her er et godt råd,
hvis man bruger en non-kodeeditor som f.eks. Notepad, og det er HELT
ufarligt optimering.

Normalt, når man koder, bruger mange spaces til at lave indrykning.
Her f.eks. tre spaces til én indrykning. Det er nok fordi, mange ikke
kan lide den faste indrykning, som en TAB laver...

Bruger man en kodeeditor i stedet for notepad, så kan man erstatte
denne gruppe af spaces med TABs, og så i editorens settings bestemme,
hvor mange spaces én tab skal fylde.

Vil det optimere meget?

Ja, har man et projekt på lad os sige 1000 linjer eller 77kb, så kan
man nemt få skåret 10kb af. Meget nemt. Ved jeg af erfaring...


MVH
Rune Jensen

[Rune Jensen]

On 27 Jan., 11:52, Leif Neland <l...@neland.dk> wrote:

> Koden er ikke uoverskuelig:
>
>  foreach($this->items_flat as $item)
>  {
>     $kattree[$item['ParentId']]['children'][$item['id']]=$item;
>
> $kattree[$item['id']]=&$kattree[$item['ParentId']]['children'][$item['id']] ;
>  };

Nej, måske ikke :)

Men som et lille PS... Du har nok allerede tænkt tanken, men hvis det
er databaseoptimering, kunne du prøve at spørge i databasegruppen.


MVH
Rune Jensen

[Leif Neland]

Rune Jensen har bragt dette til os:

Når det drejer sig om 6 vs 7.5 ms, tror jeg ikke jeg vil bruge mere tid
på det :-)

[Jonathan Stein]

Den 27-01-2013 11:56, Rune Jensen skrev:

> Bruger man en kodeeditor i stedet for notepad, s� kan man erstatte
> denne gruppe af spaces med TABs, og s� i editorens settings bestemme,
> hvor mange spaces �n tab skal fylde.
>
> Vil det optimere meget?

Jeg tvivler p�, at det vil v�re m�lbart.

Hvis man har problemer med performance, vil jeg foresl� APC, og s�
bliver mellemrum, kommentarer o.s.v. n�rmest ligegyldige.

M.v.h.

Jonathan

[runeof...@hotmail.com]

On 27 Jan., 13:36, Jonathan Stein <jst...@image.dk> wrote:

> His man har problemer med performance, vil jeg foresl APC, og s

> bliver mellemrum, kommentarer o.s.v. n rmest ligegyldige.

Mjah. Jeg tænkte nu mere på dem, som gerne vil holde deres includes på
et minimum. Der er forskel på, om man includer 40kb eller kun 20, og
det kan ses i hastighed , des større includen er. Jeg oplevede også
dette med AJAX, hvor et script blev kaldt kontinuerligt på serveren.

Men derudover, så er det EMM god stil, at man kan stole på at
indrykningen er det samme hver gang i koden.

Men det er en anden diskussion :)


MVH
Rune Jensen

[Jonathan Stein]

Den 27-01-2013 14:24, runeof...@hotmail.com skrev:

>> His man har problemer med performance, vil jeg foresl APC, og s
>> bliver mellemrum, kommentarer o.s.v. n rmest ligegyldige.
>

> Mjah. Jeg t�nkte nu mere p� dem, som gerne vil holde deres includes p�
> et minimum. Der er forskel p�, om man includer 40kb eller kun 20, og
> det kan ses i hastighed , des st�rre includen er.

Jeg regner med, at vi taler PHP kildekoden? Med APC vil der ikke v�re
forskel p� hastigheden (bortset fra f�rste request), uanset hvor mange
kommentarer og mellemrum/tabs, der er i koden.

Hvis vi taler om output til klienten, kan man overveje at gzip'e det. S�
vil forskellen p� tab og mellemrum v�re minimal.

M.v.h.

Jonathan