Tuning et questions diverses.

Version imprimable

18/06/2007, 12h13
Arvulis

Tuning et questions diverses.

Bonjour à tous,

J'ai un souvenir que dans les requetes il vaut mieux preferer la multiplication que la division..

Exemple :

Code:

Select Moyenne * 0.5 from Salaire

est à préférer à :

Code:

Select Moyenne/2 from Salaire

mais je ne sais plus expliquer pourquoi :?

Quelqu'un pourrai me redonner l'explication ?
Aussi, pour tracer le temps d'execution sur Oracle, on utilise EXPLAIN ?

Merci à tous

non, explain plan ne va pas faire de différence. Je n'ai jamais entendu cet argument et je me demande quelles sont les sources de ton souvenir :?

Cependant un petit test avec "set timing on" semble te donner raison !

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
SQL> set timi on
SQL> declare
  2    x number := 1e125;
  3  begin
  4    while (x>1e-125) loop
  5      x:= x/1.024;
  6    end loop;
  7    dbms_output.put_line(x);
  8  end;
  9  /
9.987399874996398649557681861904371420640000000000000000000000000000000000000000000000000000000E-126
 
PL/SQL procedure successfully completed.
 
Elapsed: 00:00:00.14
SQL> declare
  2    x number := 1e125;
  3  begin
  4    while (x>1e-125) loop
  5      x:= x*0.9765625;
  6    end loop;
  7    dbms_output.put_line(x);
  8  end;
  9  /
9.987399874996398649557681861904371420640000000000000000000000000000000000000000000000000000000E-126
 
PL/SQL procedure successfully completed.
 
Elapsed: 00:00:00.06

18/06/2007, 13h11
laurentschneider

peut-être parceque lorsque tu effectues une opération

a/b

Oracle doit d'abord s'assurer que b est non-null...
18/06/2007, 14h03
Arvulis

Citation:

Envoyé par laurentschneider

peut-être parceque lorsque tu effectues une opération

a/b

Oracle doit d'abord s'assurer que b est non-null...

Oui c'est peut être ça !
Mais c'est vrai que c'est un peu fou ce truc :D
18/06/2007, 14h25
doukem

Cette différence de temps de calcul ne dépend pas d'Oracle.
C'est juste d'un point de vue du processeur, que la division est beaucoup plus coûteuse que la multiplication.
18/06/2007, 14h43
laurentschneider

si tu le dis... une référence pour appuyer ton propos?
18/06/2007, 14h44
laurentschneider

note que Oracle a format de nombre propriétaire...
18/06/2007, 17h08
Arvulis

on aura pas la confirmation du monsieur :cry:

tu peux aussi voir avec DBMS_PROFILER ce qui est plus rentable..
mais bon, c'est du tuning extrême à mon sens.

Voici l'exemple de F degrelle je crois

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
CREATE OR REPLACE PROCEDURE TEST_PROFILER
IS
  TYPE TYP_TV1 IS TABLE OF VARCHAR2(50) INDEX BY BINARY_INTEGER ;
  TYPE TYP_TV2 IS TABLE OF VARCHAR2(50) INDEX BY PLS_INTEGER ;  
  i1  PLS_INTEGER ;
  n1  NUMBER ;
  v1  VARCHAR2(2000) ;
  t1  TYP_TV1 ;
  t2  TYP_TV2 ;
  d1  DATE ;  
 
UNIT_NAME       OCCURED TOT_TIME          LINE TEXT
--------------- ------- ----------- ---------- ---------------------------------------------------
<anonymous>           2     .000084          4
<anonymous>           1     .000006          5
TEST_PROFILER         1     .000063          1 PROCEDURE TEST_PROFILER
TEST_PROFILER      1001     .000653         13   For i IN 1 .. 1000 Loop
TEST_PROFILER      1000     .001463         16   n1 := i ;
TEST_PROFILER      1000     .005228         17   v1 := i ;
TEST_PROFILER      1000     .005106         18   v1 := To_char( i ) ;
TEST_PROFILER      1000     .007010         19   v1 := Ltrim( To_Char( i ) ) ;
TEST_PROFILER      1000     .007110         20   v1 := Replace( To_Char( i ), ' ', '' ) ;
TEST_PROFILER      1000     .003209         21   i1 := Instr( v1, '0' ) ;
TEST_PROFILER      1000     .003021         22   v1 := Substr( v1, 1, 1 ) ;
TEST_PROFILER      1000     .006956         23   t1(i) := i ;
TEST_PROFILER      1000     .002220         24   t2(i) := i ;
TEST_PROFILER      1000     .006157         25   n1 := Round( i * 1.37 ) ;
TEST_PROFILER      1000     .002388         26   n1 := Trunc( i * 1.37 ) ;
TEST_PROFILER      1000     .002861         27   n1 := Round( i * 1.37999999999999 ) ;
TEST_PROFILER      1000     .001619         28   n1 := Trunc( i * 1.37999999999999 ) ;
TEST_PROFILER      1000     .011119         29   d1 := SYSDATE + i ;
TEST_PROFILER         1     .000065         33 END TEST_PROFILER ;
 
As we can see, PLS_INTEGER type is 4/5 times faster than NUMBER
The NESTED TABLE INDEX BY PLS_INTEGER is 3 times faster than the INDEX BY BINARY_INTEGER
Operation on double-precision number is faster than operation on single-precision number
 
Francois

18/06/2007, 18h09
laurentschneider

Citation:

Envoyé par McM

mais bon, c'est du tuning extrême à mon sens.

ça s'est sûr! c'est de l'ordre de quelques micro-secondes...
19/06/2007, 14h31
doukem

Je n'ai pas de référence, si ce n'est mes cours de fac, ce sont les règles de base qu'on apprend lorsqu'on veut optimiser ses programmes, qui sont valables pour la plupart des processeurs. C'est connu qu'une division est plus coûteuse qu'une multiplication.
Maintenant si Oracle a son propre format de nombre, effectivement ça n'est peut-être pas vrai ici, mais à mon avis ils n'ont pas recodé toutes les opérations de base, celles-ci étant par défaut présentes de manière optimisées sur les tous les processeurs.

en fait ce n'est qu'en 10gR1 que sont apparues les opérations en virgules flottantes, 10x plus rapide que NUMBER, avec le type de donnée BINARY_DOUBLE (et binary_float). NUMBER, c'est vraiment un format Oracle pur, pas optimisé pour les opérations style division / multiplication...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
SQL> declare
  2        x binary_double := 1e125d;
  3      begin
  4        while (x>1e-125d) loop
  5          x:= x/1.024d;
  6        end loop;
  7        dbms_output.put_line(x);
  8  end;
  9  /
 
PL/SQL procedure successfully completed.
 
Elapsed: 00:00:00.03
SQL> declare
  2        x binary_double := 1e125d;
  3      begin
  4        while (x>1e-125d) loop
  5          x:= x/1.024d;
  6        end loop;
  7        dbms_output.put_line(x);
  8  end;
  9  /
 
PL/SQL procedure successfully completed.
 
Elapsed: 00:00:00.03

19/06/2007, 15h03
doukem

Je ne vois pas en quoi ma réponse n'est pas bonne. Le fait que ces opérations soient apparues récemment ne veut pas dire que multiplications et divisions ne sont pas réalisées par l'UAL du processeur.

Pourquoi le type NUMBER n'est pas optimisé ? Surement parce qu'il doit être converti en entier "standard" pour être additionné ou multiplié, ou alors parce que les opérateurs de base sont redéfinis pour ce type. Dans tous les cas, ça n'a pas de rapport non plus, je ne vois pas pourquoi les divisions ne seraient pas plus coûteuses que les multiplications.

Mes cours de fac sont peut-être sympas, mais tes connaissances en Oracle aussi, parce que tu cherches des explications "Oracle" à des problèmes de base. L'algorithme de la division est plus compliqué de celui de la multiplication, quel que soit ton format de nombre. Si c'est le cas depuis des années pour les processeurs, je ne vois pas pourquoi les développeurs d'Oracle auraient résolu le problème avec leur format spécifique.
19/06/2007, 15h40
laurentschneider

oui, tu as raison, le type NUMBER, c'est des opérations sur des "entiers" et le type BINARY_DOUBLE, c'est sur des "virgules flottantes".

Si tu peux nous éclairer sur la raison pourquoi une division serait plus lente, ça serait sympa :roll:
19/06/2007, 16h11
doukem

Malheureusement je ne trouve pas l'explication "officielle". Ce qui est sûr, c'est que ça devient un peu hors sujet vu que ça ne dépend pas d'Oracle ni du SQL en général.
C'est une règle qu'on apprend dans tous les langages de programmation, car dans tous les langages ces opérations sont réalisées par le processeur, mais l'explication est....

Si j'ai le temps je chercherai pourquoi :(

Ou bien j'ai tort, et ce serait intéressant de le savoir, car on est plusieurs dans ce cas. (la preuve, le 1er post de ce topic comment par "J'ai un souvenir que dans les requetes il vaut mieux preferer la multiplication que la division")
19/06/2007, 16h33
McM

Au niveau CPU : Les calculs de divisions sont plus lourds que ceux de multiplication. Et les différences dépendent aussi des processeurs.
Tout est question de cycles.

Un article de hardware.fr de 2006 qui fait un comparatif
http://www.hardware.fr/articles/623-...o-dossier.html

Mais je reste persuadé que les différences au niveau oracle restent minimes.
Généralement c'est pas la CPU des serveurs qui rame.