---

Hej

Jeg har lavet et script, som foretager i alt otte SQL-kald.

Jeg har kompileret dem alle i begyndelsen af scriptet, men flere af dem er
relativt korte uden bind-værdier.

Hvad er mest effektivt
- at kompilere SQL som nu?
- at kompilere de større strenge og blot afvikle de små?

Sig til, hvis I mangler info.

Mvh
Jimmy

---

On Thursday 27 February 2003 01:27 it appears that Jimmy wrote:

> Hej
>
> Jeg har lavet et script, som foretager i alt otte SQL-kald.
>
> Jeg har kompileret dem alle i begyndelsen af scriptet, men flere af dem er
> relativt korte uden bind-værdier.

Når du siger 'kompileret' så mener du vel 'kaldt prepare'?
For du bruger da DBI og DBD::??? ik' os'?

>
> Hvad er mest effektivt
> - at kompilere SQL som nu?
> - at kompilere de større strenge og blot afvikle de små?

Det afhænger af mange ting. Især af hvilken database du benytter, der er
*MEGET* stor forskel på hvad de forskellige DBD-drivere (og
databasesystemer) gør ved prepare.
Det varierer lige fra slet ikke at gøre noget udover at gemme SQL-teksten
til at lave queryplan og forberede hele din query.
Der er kun en sikker måde at finde ud af det på: mål!

Hvis du ikke bruger enormt lang tid i SQLkaldene og du ikke gentager den
voldsomt mange gange i scriptet kan det næsten være ligegyldigt.
Ved at prepare én gang istedet for flere gange sparer du (måske) noget
arbejde for database bagenden, men du gør (måske) dit program mere
kompliceret og sværere at vedligeholde.

Gør det på den måde, der virker enklest når du koder. Hvis (bemærk: HVIS) du
får performance problemer, så MÅL hvor problemerne er og TEST om den
ændring du påtænker afhjælper problemet.
Som regel er det helt andre steder end der man i første omgang tror at
problemerne er, at de i virkeligheden dukker op.

mvh
Henrik

> Sig til, hvis I mangler info.
>
> Mvh
> Jimmy

---

"Henrik Tougaard" <htoug@hotmail.com> wrote in message
news:5kdk3b.1r4.ln@linux.local...
> On Thursday 27 February 2003 01:27 it appears that Jimmy wrote:
>
> > Hej
> >
> > Jeg har lavet et script, som foretager i alt otte SQL-kald.
> >
> > Jeg har kompileret dem alle i begyndelsen af scriptet, men flere af dem
er
> > relativt korte uden bind-værdier.
>
> Når du siger 'kompileret' så mener du vel 'kaldt prepare'?
> For du bruger da DBI og DBD::??? ik' os'?


Jojo samt MySQL

> Der er kun en sikker måde at finde ud af det på: mål!

God ide - Skal jeg:

print time();
...
print time();

Eller findes der mere effektive måder?


> Hvis du ikke bruger enormt lang tid i SQLkaldene

Scriptet tager en 5-6 sekunder at udføre, (porteret fra asp, hvor det tog
under et sekund).

Jeg er ganske givet ikke dygtig til perl og har sikkert kodet det
uhensigtsmæssigt i forhold til hvordan man normalt gør i perl, men jeg
forestiller mig, at det er SQL-kaldene jeg skal have optimeret.
Jeg kan desværre ikke spare nogen væk

Tak for svaret.

Mvh
Jimmy

---

I dk.edb.programmering.perl, skrev Jimmy:
> Scriptet tager en 5-6 sekunder at udføre, (porteret fra asp, hvor det tog
> under et sekund).

Hvordan kører du det? Benytter du mod_perl vil du sandsynligvis kunne
opnå en hastigheds forbedring.

Da du siger det er portet fra asp, så antager jeg at det er et
cgi-script til en apache server.

--
../Jesper Krogh, jesper@krogh.cc
Jabber ID: jesper@jabber.krogh.cc
PGP Key: 0x4F57020E http://krogh.cc/public.asc

---

"Jesper Krogh" <jesper@krogh.cc> wrote in message
news:b3la8e$sq9$1@r2d2.krogh.cc...
> I dk.edb.programmering.perl, skrev Jimmy:
> > Scriptet tager en 5-6 sekunder at udføre, (porteret fra asp, hvor det
tog
> > under et sekund).
>
> Hvordan kører du det? Benytter du mod_perl vil du sandsynligvis kunne
> opnå en hastigheds forbedring.

mod_perl siger mig ikke noget.
Hvad er dette?


> Da du siger det er portet fra asp, så antager jeg at det er et
> cgi-script til en apache server.

Nej faktisk ikke.
Det er et asp-script, som jeg har portet til et helt almindeligt .pl
program.
Der er slet ikke Apache på maskinen.

Mvh
Jimmy

---

Thu, 27 Feb 2003 at 12:40 GMT Jimmy wrote
>
> Scriptet tager en 5-6 sekunder at udføre, (porteret fra asp, hvor det tog
> under et sekund).

Din asp holder sikkert databaseforbindelsen. Dit perl program skal etablere
den for hver kørsel.
Hvis jeg ikke gætter meget forkert startes dit perlkode fra cron på en
minimalistisk linux kasse, ikk?
Her er det også kostbart at starte perl og få loadet diverse moduler.

> Jeg er ganske givet ikke dygtig til perl

Nej, men nu har du da "Programming perl" ved hånden, så mon ikke det kommer?

Iøvrigt tror jeg ikke der er nogen nævneværdig hastighedsforskel på
om du "prepare" dine SQL'er inden brug hvis de alligevel kun køres en
enkelt gang for hver gang du starter din applikation.


/Morten

---

"Morten Guldager" <spamtrap@mogul.dk> wrote in message
news:slrnb5sl2m.ccf.spamtrap@linuxine.mogul.dk...
> Thu, 27 Feb 2003 at 12:40 GMT Jimmy wrote
> >
> > Scriptet tager en 5-6 sekunder at udføre, (porteret fra asp, hvor det
tog
> > under et sekund).
>
> Din asp holder sikkert databaseforbindelsen. Dit perl program skal
etablere
> den for hver kørsel.

ASP holder den åben, ja.
Dvs. der forhandles user/pass hver gang jeg afvikler et SQL-kald?

> Hvis jeg ikke gætter meget forkert startes dit perlkode fra cron på en
> minimalistisk linux kasse, ikk?

Jojo

> Her er det også kostbart at starte perl og få loadet diverse moduler.

Ja så hjælper det nok ikke, at jeg kalder Date::Manip


> > Jeg er ganske givet ikke dygtig til perl
>
> Nej, men nu har du da "Programming perl" ved hånden, så mon ikke det
kommer?




> Iøvrigt tror jeg ikke der er nogen nævneværdig hastighedsforskel på
> om du "prepare" dine SQL'er inden brug hvis de alligevel kun køres en
> enkelt gang for hver gang du starter din applikation.

Oki doki.
Tak for hjælpen til alle.

Mvh
Jimmy

---

Thu, 27 Feb 2003 at 19:17 GMT Jimmy wrote
> Dvs. der forhandles user/pass hver gang jeg afvikler et SQL-kald?

Nej, kun i DBI->connect kaldet.

>> Hvis jeg ikke gætter meget forkert startes dit perlkode fra cron på en
>> minimalistisk linux kasse, ikk?
>
> Jojo

Så der forhandles altså user/password hver gang cron starter dit program.


/Morten

---

"Jimmy" <nyhedsgruppe@get3_erstat_3_med_2_net.dk> writes:

> God ide - Skal jeg:
>
> print time();
> ...
> print time();
>
> Eller findes der mere effektive måder?

Se på Benchmark-modulet.

> Jeg er ganske givet ikke dygtig til perl og har sikkert kodet det
> uhensigtsmæssigt i forhold til hvordan man normalt gør i perl, men jeg
> forestiller mig, at det er SQL-kaldene jeg skal have optimeret.

Der er spildt så forfærdelig meget tid på at optimere på forkerte
stykker kode. Benchmarking spare tid i enden.

--
Peter Makholm | First you fall in love with Antarctica, and then it
peter@makholm.net | breaks your heart
http://hacking.dk | -- Antarctica

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Makholm <peter@makholm.net> writes:

> "Jimmy" <nyhedsgruppe@get3_erstat_3_med_2_net.dk> writes:
>
>> God ide - Skal jeg:
>>
>> print time();
>> ...
>> print time();
>>
>> Eller findes der mere effektive måder?
>
> Se på Benchmark-modulet.

Naar vi nu snakker DBI kan jeg foreslaa DBI::Profile, hint:
....
BEGIN {
$ENV{DBI_PROFILE} = 10;
}
use DBI;
....


- --
Dennis
I have always thought explanations were overkill when correcting
mistakes. A simple "that's wrong" must suffice. I mean, people are
always aware why they are wrong. They just make mistakes to annoy you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE+Y1sfo6hqeoa8JFgRAvs4AKDBKiV/vtMUQ2+gTE/Y5sIOV3JPKQCfRwfO
VWEGmDpMtfvZof6NxoK+FYY=
=Ma6x
-----END PGP SIGNATURE-----

---

On Thu, 27 Feb 2003 01:27:05 +0100, Jimmy wrote:

> Hvad er mest effektivt - at kompilere SQL som nu? - at kompilere de
> større strenge og blot afvikle de små?

- at måle på dit program, og se om det overhovedet er flaskehalsen?


Mvh.

--
"I try to make everyone's day a little more surreal" Adam Sjøgren
asjo@koldfront.dk