Tijdconversie in PHP of MySQL: wat is sneller?

[Rekcor]

Ik heb een database met daarin een kolom UNIX timestamps. Deze wil ik converteren naar datumstrings.

Mijn vraag: wat is sneller, in de query al converteren mbv FROM_UNIXTIME of later converteren mbv PHP's date functie? Ongeacht welke functie, wat is sowieso de snelste oplossing?

P.S. Je zou kunnen zeggen 'probeer het eens uit', maar mijn database is nu nog niet zo groot, waardoor alles 0.003 s duurt

[Cavorka]

Maak een benchmark: 10000x uitproberen, dan zul je vast wel een verschil zien.

Dat lijkt me enige manier om iets met zekerheid te kunnen zeggen.

[LuCarD]

* LuCarD mopelt iets over programmer time en computer time.

Wat ik daar mee wil zeggen, denk je dat het zoveel zal uitmaken dat het een echte impact op je systeem heeft?

[sariel]

Rekcor schreef op maandag 30 oktober 2006 @ 13:36:
Ik heb een database met daarin een kolom UNIX timestamps. Deze wil ik converteren naar datumstrings.

Mijn vraag: wat is sneller, in de query al converteren mbv FROM_UNIXTIME of later converteren mbv PHP's date functie? Ongeacht welke functie, wat is sowieso de snelste oplossing?

P.S. Je zou kunnen zeggen 'probeer het eens uit', maar mijn database is nu nog niet zo groot, waardoor alles 0.003 s duurt

En als je database niet zo groot is, dan vul je die toch gewoon?
Maak een klein scriptje dat je database vult met bogus waarden en een timestamp (rand(1,1000000000);).
Maak dan een scriptje dat alle velden leest en converteerd met date
Maak dan een scriptje dat alle velden leest en converteerd met FROM_UNIXTIME

Welke van de laatste 2 doet er langer over?

[Rekcor]

LuCarD schreef op maandag 30 oktober 2006 @ 13:40:
* LuCarD mopelt iets over programmer time en computer time.

Wat ik daar mee wil zeggen, denk je dat het zoveel zal uitmaken dat het een echte impact op je systeem heeft?

Nee, het is ook meer uit nieuwsgierigheid... Ik wilde gewoon weten of hier vuistregels voor zijn.

[ Voor 7% gewijzigd door Rekcor op 30-10-2006 13:48 ]

[Cavorka]

Rekcor schreef op maandag 30 oktober 2006 @ 13:44:
[...]
Nee, het is ook meer uit nieuwsgierigheid... Ik wilde gewoon weten of hier vuistregels voor zijn.

Hm, vuistregel 1 dan maar: meten is weten.

[Michali]

En meten op het juiste systeem. Een ander OS of andere hardware kan nog wel eens voor andere resultaten zorgen.

[Janoz]

Waarom zou je je willen bezig houden met dit soort micro optimalizaties? Voor die paar ms winst verlies je vervolgens een boel duidelijkheid in je code. Waarom heb je je datum eigenlijk als unix timestamp opgeslagen? Het lijkt me veel makkelijker om gewoon een date type te gebruiken. Bij het uitlezen kun je die middels UNIX_TIMESTAMP keurig naar een unix timestamp omzetten. Door datum velden te gebruiken kun je in je queries gebruik maken van de vele datetime functies (month(), now(), enz)

In je buisness logic kun je vervolgens heel makkelijk met de timestamp werklen omdat php hier leuk mee om kan gaan. Je datum converteren naar de manier waarop het gepresenteerd moet worden is iets dat je typisch helemaal aan het einde doet op het moment dat deze afgedrukt moet worden. In je view dus (voor zover je dat uberhaupt ergens tegenkomt in een php applicatie, maar dat is een andere discussie).

Doro dit uti te zoeken en alvast in je DB te converteren verdien je nu misschien een paar micro seconden, later zal het je waarschijnlijk op gaan breken omdat je php code een onbeheersbare bende geworden is.

[roy-t]

Ik weet het niet, ik ben het wel met de TS eens, al is het maar 0.1microseconde per file tegenwoordig vul je een database zo snel dat het zeker de optimalisatie waard is om dit uit te zoeken, ook weten we nu niet hoe vaak dit commando uitgevoerd zal worden.

Duidelijkheid in je code kun je altijd nog scheppen met comments, en ik denk niet dat je veel duidelijkheid verliest door het of in php of in mysql te doen

[Michali]

En dan neemt de rest van het script relatief 5000% zo veel tijd in beslag. (Niet dat ik beweer dat het zo is.) Nou, wat nuttig is die optimalisatie dan geweest zeg. Het punt dat ik probeer te maken is dat je van te voren geen rekening met dit soort zaken moet houden. Profile je applicatie achteraf, waarmee je gelijk de knelpunten tegenkomt. Hier kun je dan, waar nodig, mee gaan werken.

@hierboven: Bekend met de zin "premature optimization is the root of all evil"? Zoek maar eens op Google op.

[ Voor 12% gewijzigd door Michali op 30-10-2006 14:40 ]