Profiling d'un Byref vs Byval

[EvaristeGaloisBis]

Bonjour,

Un collegue est moi avons voulu tester la difference de rapidité entre un appel par byval et un byref. Nous pensions que le ByRef allait remporter la bataille au la main.. Et ô suprise ! Non ! C'est le ByVal qui a mis moins de temps.
Alors nous ne comprenons pas notre résultat. Quelqu'un pourrait il confirmer ou infirmer notre résultat?

[ucfoutu]

Bonjour,

Ta question n'en n'est pas une vraie...
Et la réponse dépend de ton code ...
ByRef(par défaut), passe une valeur par référence
Byval (à spécifier) passe la valeur telle qu'elle est au moment du passage.

Il y a des cas où ByRef est nécessaire et d'autres ou Byval suiffit (et va alors plus vite, bien évidemment)...
Alors : sans ton code, ma foi (et ses commentaires ad hoc) ==>> réponse de Normand !

[Pierre Fauconnier]

Bonjour

Cela me fait toujours sourire quand on parle de performances, là ou par ailleurs le code est rarement, voire jamais, optimisé... Mais bon...

Je serais curieux de voir la justification de ucfoutu sur le fait que byval soit évidemment plus rapide. Intuitivement, j'aurais dit l'inverse, puisque ByRef pointe vers quelque chose qui existe alors que ByVal crée une copie.

De plus, pour ma part, je pense qu'il ne faut pas les différencier sur la performance, mais sur la finalité.

Avec ByRef, je donne la possibilité au code qui reçoit le paramètre de modifier la variable d'origine (et donc de retrouver cette modification dans le code appelant à la sortie de la procédure modificatrice, avec toutes les conséquences, utiles ou néfastes, que cela induit), alors qu'avec ByVal, je verrouille la variable d'origine et transfère "seulement" une copie. Pour moi, c'est là l'unique raison d'utiliser l'un plutôt que l'autre, indépendamment de toute "performance" dont la mesure ne peut bien souvent être réalisée, en VBA, que de façon tellement théorique qu'elle en perd toute utilité.

[ucfoutu]

Envoyé par Pierre Fauconnier

Je serais curieux de voir la justification de ucfoutu sur le fait que byval soit évidemment plus rapide.

Bonjour, dès lors que ByRef est utilisé, VB (qui à ma connaissance ne fait pas la différence "en son propre sein" entre le fait qu'une variable a ou non été modifiée) provoque systématiquement un second accès à l'adresse-mémoire (celle que retourne par exemple VarPtr) pour "mettre à jour" la variable (modifiée ou non).
Aucun gain de temps réellement significatif sur une seule opération, avec une seule variable. Plusieurs variables passées ByRef dans une fonction appelée en boucle un grand nombre de fois et c'est une toute autre paire de manches ...
J'ajoute que l'utilisation de Byref est potentiellement dangereuse, si le développeur est un étourdi. Plusieurs discussions sur le net dénoncent d'ailleurs l'imprudence qu'à commise VB en faisant de ByRef le type de passage par défaut.
Pour le reste (la performance du reste des applications très ..moyennes.. dont nous sommes bien souvent les spectacteurs), je suis d'accord avec toi...

[Pierre Fauconnier]

Sur le fait que ByRef soit par défaut à la place de Byval, je suis d'accord avec toi. Il faudrait que je lise d'autres sources pour me faire une opinion sur le reste de ton explication.

Mais je reste toujours, comme toi semble-t-il, perplexe quant à une véritable optimisation du code grâce à des "trucs" comme celui-là, en tout cas en VBA, voire même en VB6, pour la plupart des "applications" dont on parle sur nos forums.

J'ai eu dernièrement une discussion sur ce forum sur le fait de savoir s'il était plus performant d'utiliser

If i = 1 Then
    ...
End If
If i = 2 Then
    ...
End If

ou

Select Case i
    Case 1
        ...
    Case 2
        ...
End Select

. La personne qui soutenait que le bloc Select End Select était plus rapide me l'a démontré grâce à une boucle

For i = 1 to 1000000000

qui donnait une différence de 2 secondes (et encore, pas toujours) sur un temps d'exécution de 36 à 38 secondes (donc, 0 secondes pour des nombres de boucles habituellement réalisés dans une appli)... C'est vrai qu'avec VBA, on boucle tout le temps 1 milliard de fois au minimum .

Donc, au delà de la taquinerie, cela me fait souvent marrer quand on vient parler de performances...

[EvaristeGaloisBis]

bonjour,
J'arrive un peu après la bataille...
Pour le code de comparaison entre byref et byval, j'ai utilisé une boucle comme celles dont Pierre fait allusion.

Je ne savais pas que l'envoie par defaut est byref. Ce qui pourrait expliquer l'origine de nos resultats ( sur une echelle du temps : rien<byval<byref). En tout cas en apprenant ça, je crois que je n'ecrirai plus des:

sub truc(byref var as VarTyp)
end sub

[=JBO=]

Bonjour,

Envoyé par EvaristeGaloisBis

Je ne savais pas que l'envoie par defaut est byref.
[...]
En tout cas en apprenant ça, je crois que je n'ecrirai plus des:

sub truc(byref var as VarTyp)
end sub

A moins de programmer tout seul dans ton coin (et là fais bien comme tu voudras) je te conseillerai plutôt de continuer à déclarer explicitement Byref ou Byval.
En effet, en utilisant ces mots-clés tu explicites ton intention quant au passage d'argument et la possibilité/nécessité de les modifier dans la procédure concernée.

Cela participe de la "documentation" de ton code (surtout s'il n'y a pas de commentaire) en vue de son partage avec d'autres développeurs, ou même simplement pour t'aider à te rappeler la façon d'appeler ta procédure.

Petit témoignage:
lors d'appels de procédures/fonctions, j'ai souvent besoin de "remonter" des informations en plus du résultat (retourné dans le cas d'une fonction).
Aussi, je "documente" les paramètres concernés dans la procédure avec un suffixe "_out" (genre langage ADA) qui me rappelle que le paramètre est utilisé pour "retourner" une valeur.

Exemple:

Public Function FichierExiste(sNomFichier As String, _
                            Optional ByRef nTailleFichier_out As Long) As Boolean
 
End Function

_