Y a-t-il un gain de performance en utilisant des guillemets simples par rapport aux guillemets doubles en rubis?


126

Savez-vous si l'utilisation de guillemets doubles au lieu de guillemets simples dans ruby ​​diminue les performances de manière significative dans ruby ​​1.8 et 1.9.

donc si je tape

question = 'my question'

est-ce plus rapide que

question = "my question"

J'imagine que ruby ​​essaie de déterminer si quelque chose doit être évalué lorsqu'il rencontre des guillemets doubles et passe probablement quelques cycles à le faire.


17
Exécutez-le un demi-million de fois et voyez. Il y a de fortes chances que votre site n'obtienne pas assez de trafic pour avoir de l'importance. L'optimisation prématurée n'en vaut généralement pas la peine.
ceejayoz

60
Pourquoi tant de gens s'attendent-ils à ce que ruby ​​ne soit utilisé que pour la programmation Web?
johannes

17
Je ne considérerais pas cette optimisation prématurée. Il s'agit davantage d'une "meilleure pratique", car revenir en arrière une fois votre application terminée et l'optimisation pour un simple ou un double serait un énorme casse-tête.
Omar

7
Pour moi, c'est juste du style: j'utilise des guillemets simples pour les chaînes «statiques» et des doubles qoutes (ou d'autres chaînes interpolées) dans d'autres cas.
tig

3
@Baddie: C'est une optimisation prématurée si vous optimisez un problème qui n'existe pas.
Andy Lester

Réponses:


86
$ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.0.0]

$ cat benchmark_quotes.rb
# As of Ruby 1.9 Benchmark must be required
require 'benchmark'

n = 1000000
Benchmark.bm(15) do |x|
  x.report("assign single") { n.times do; c = 'a string'; end}
  x.report("assign double") { n.times do; c = "a string"; end}
  x.report("concat single") { n.times do; 'a string ' + 'b string'; end}
  x.report("concat double") { n.times do; "a string " + "b string"; end}
end

$ ruby benchmark_quotes.rb 

                      user     system      total        real
assign single     0.110000   0.000000   0.110000 (  0.116867)
assign double     0.120000   0.000000   0.120000 (  0.116761)
concat single     0.280000   0.000000   0.280000 (  0.276964)
concat double     0.270000   0.000000   0.270000 (  0.278146)

Remarque: j'ai mis à jour cela pour le faire fonctionner avec les versions plus récentes de Ruby, j'ai nettoyé l'en-tête et exécuté le benchmark sur un système plus rapide.

Cette réponse omet certains points clés. Voir en particulier ces autres réponses concernant l' interpolation et la raison pour laquelle il n'y a pas de différence significative de performances lors de l'utilisation de guillemets simples ou doubles.


Est-ce que j'interprète correctement les résultats? L'affectation en utilisant des guillemets doubles est en fait plus rapide que les simples? Comment se peut-il?
randomguy

Apparemment oui, bien que la différence soit mineure. Quant à savoir pourquoi - me bat.
zetetic

Ce benchmark serait beaucoup plus convaincant s'il prenait en compte le temps de compilation ainsi que le temps d'exécution.
nohat

9
Les différences mesurées ne sont pas significatives. La simple commande (à cause du garbage collection) peut faire une différence importante. Il n'y a pas de différence d'exécution entre 'et "car ils sont analysés à la même chose.
Marc-André Lafortune

104

Résumé: pas de différence de vitesse; ce grand guide de style collaboratif Ruby recommande d'être cohérent. J'utilise maintenant 'string'sauf si une interpolation est nécessaire (option A dans le guide) et je l'aime, mais vous verrez généralement plus de code avec "string".

Détails:

Théoriquement, cela peut faire une différence lorsque votre code est analysé , mais non seulement si vous ne vous souciez pas du temps d'analyse en général (négligeable par rapport au temps d'exécution), vous ne pourrez pas trouver de différence significative dans ce cas.

L'important est que quand il sera exécuté, ce sera exactement la même chose .

L'analyse comparative montre seulement un manque de compréhension du fonctionnement de Ruby. Dans les deux cas, les chaînes seront analysées en a tSTRING_CONTENT(voir la source dansparse.y ). En d'autres termes, le CPU effectuera exactement les mêmes opérations lors de la création 'string'ou "string". Les mêmes bits seront inversés exactement de la même manière. L'analyse comparative ne montrera que les différences qui ne sont pas significatives et dues à d'autres facteurs (démarrage du GC, etc.); rappelez-vous, il ne peut y avoir aucune différence dans ce cas! Les micro-benchmarks comme ceux-ci sont difficiles à obtenir. Voir mon bijou fruitypour un outil décent pour cela.

Notez que s'il y a interpolation de la forme "...#{...}...", celle-ci est analysée en a tSTRING_DBEG, un groupe de tSTRING_DVARpour chaque expression dans #{...}et une finale tSTRING_DEND. Ce n'est que s'il y a interpolation, ce qui n'est pas le but de l'OP.

J'avais l'habitude de vous suggérer d'utiliser des guillemets doubles partout (il est plus facile de l'ajouter #{some_var}plus tard), mais j'utilise maintenant des guillemets simples sauf si j'ai besoin d'une interpolation \n, etc ... Je l'aime visuellement et c'est un peu plus explicite, car besoin d'analyser la chaîne pour voir si elle contient une expression.


3
Cela semble beaucoup plus important que la différence de performance infime. Les guillemets doubles c'est!
Venkat D.

Merci de m'avoir indiqué votre réponse. Pouvez-vous préciser pourquoi vous dites que l'analyse comparative est trompeuse? Je conviens que les différences sont probablement négligeables, mais la référence est-elle en quelque sorte erronée? (Quelqu'un a déjà souligné #{n}qu'il ferait une conversion de nombre). Ne montre-t-il pas les différences d'analyse ?.
PhilT

1
Merci d'avoir créé un lien vers le guide de style. Je ne peux pas croire que je n'ai pas rencontré ça avant.
PhilT

1
Le guide de style mentionné dans votre réponse a été mis à jour pour suggérer l'adoption d'un style cohérent, qu'il s'agisse de guillemets simples ou doubles, et indique que les chaînes entre guillemets sont plus répandues dans la communauté Ruby.
philtr

Utilisez des guillemets doubles. La programmation est difficile. La syntaxe est intrinsèquement complexe. Les guillemets doubles signifient ne jamais faire d'erreur ou perdre du temps avec une erreur lors de la création d'une chaîne dynamique. Avec des guillemets doubles, vous avez une chose en moins à penser.
Kelsey Hannan

35

Personne n'a cependant mesuré la concaténation par rapport à l'interpolation:

$ ruby -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin9.6.2]
$ cat benchmark_quotes.rb
require 'benchmark'
n = 1000000
Benchmark.bm do |x|
  x.report("assign single") { n.times do; c = 'a string'; end}
  x.report("assign double") { n.times do; c = "a string"; end}
  x.report("assign interp") { n.times do; c = "a string #{'b string'}"; end}
  x.report("concat single") { n.times do; 'a string ' + 'b string'; end}
  x.report("concat double") { n.times do; "a string " + "b string"; end}
end

$ ruby -w benchmark_quotes.rb 
      user     system      total        real
assign single  2.600000   1.060000   3.660000 (  3.720909)
assign double  2.590000   1.050000   3.640000 (  3.675082)
assign interp  2.620000   1.050000   3.670000 (  3.704218)
concat single  3.760000   1.080000   4.840000 (  4.888394)
concat double  3.700000   1.070000   4.770000 (  4.818794)

Plus précisément, note assign interp = 2.62vs concat single = 3.76. Cerise sur le gâteau, je trouve aussi l'interpolation plus lisible que 'a' + var + 'b'surtout en ce qui concerne les espaces.


+1. C'est le seul point de repère d'interpolation qui compare des pommes avec des pommes.
Mark Thomas

1
L'analyse comparative peut être trompeuse; voyez ma réponse pour savoir pourquoi. Quant à la comparaison entre concaténation et interpolation, il doit être évident que l'interpolation ne peut pas être plus lente que la concaténation. En tout cas, cela ne fait pas vraiment partie de la question!
Marc-André Lafortune

Pouvez-vous ajouter << à ce test?
Nick

16

Aucune différence - sauf si vous utilisez l' #{some_var}interpolation de chaîne de style. Mais vous n'obtenez des performances que si vous le faites réellement.

Modifié à partir de l' exemple de Zetetic :

require 'benchmark'
n = 1000000
Benchmark.bm do |x|
  x.report("assign single") { n.times do; c = 'a string'; end}
  x.report("assign double") { n.times do; c = "a string"; end}
  x.report("assign interp") { n.times do; c = "a #{n} string"; end}  
  x.report("concat single") { n.times do; 'a string ' + 'b string'; end}
  x.report("concat double") { n.times do; "a string " + "b string"; end}
  x.report("concat interp") { n.times do; "a #{n} string " + "b #{n} string"; end}
end

production

               user       system     total    real
assign single  0.370000   0.000000   0.370000 (  0.374599)
assign double  0.360000   0.000000   0.360000 (  0.366636)
assign interp  1.540000   0.010000   1.550000 (  1.577638)
concat single  1.100000   0.010000   1.110000 (  1.119720)
concat double  1.090000   0.000000   1.090000 (  1.116240)
concat interp  3.460000   0.020000   3.480000 (  3.535724)

Intéressant. L'interpolation semble un peu plus chère. Était-ce 1,8? Ce serait bien de voir si la 1.9 change quoi que ce soit.
zetetic

zététique - ouais. C'était contre Ruby
1.8.7

1
La version interp est à la fois interpolante et concaténante et convertit deux fois un nombre en chaîne. L'interpolation gagne si vous obtenez les mêmes résultats. Voir gist.github.com/810463 . La vraie chose à retenir est de s'inquiéter davantage des to_s que des guillemets simples ou doubles.
Brian Deterling

L'analyse comparative de cela peut être trompeuse et montre un malentendu sur le fonctionnement de Ruby. Voyez ma réponse.
Marc-André Lafortune

13

Les guillemets simples peuvent être très légèrement plus rapides que les guillemets doubles car le lexer n'a pas à vérifier les #{}marqueurs d'interpolation. Selon l'implémentation, etc. Notez qu'il s'agit d'un coût d'analyse et non d'un coût d'exécution.

Cela dit, la vraie question était de savoir si l'utilisation de chaînes entre guillemets "diminue les performances d'une manière significative", à laquelle la réponse est un "non" décisif. La différence de performance est si incroyablement petite qu'elle est complètement insignifiante par rapport à tout problème de performance réel. Ne perds pas ton temps.

L'interpolation réelle est une autre histoire, bien sûr. 'foo'sera presque exactement 1 seconde plus rapide que "#{sleep 1; nil}foo".


4
+1 pour avoir noté que le coût est au moment de la compilation et non au moment de l'exécution, de sorte que les réponses de référence hautement votées ci-dessus sont trompeuses.
nohat

"il s'agit d'un coût d'analyse, pas d'un coût d'exécution." est la phrase clé.
the Tin Man

9

Les guillemets doubles nécessitent deux fois plus de frappes que les guillemets simples. Je suis toujours pressé. J'utilise des guillemets simples. :) Et oui, je considère que c'est un "gain de performance". :)


Pourquoi les guillemets doubles prendraient-ils deux fois plus de frappe? Ils sont tous deux représentés par une seule touche. De plus, de nombreux IDE ajoutent automatiquement le ou les guillemets de clôture.
Matt Dressel

3
Même si l'EDI ferme automatiquement le devis, les guillemets doubles nécessitent toujours 100% de frappes supplémentaires. ;-)
Clint Pachl

Matt Dressel: les guillemets doubles nécessitent deux fois plus de frappes sur les touches, car vous devez également appuyer sur la touche Maj. Oh: :) juste au cas où vous l'auriez manqué dans mon commentaire original. :) Les clés filaires nécessitent plus d'effort et sans doute plus de temps pour s'exécuter. :)
aqn

1
Parfois, je suis ce conseil par paresse. Mais malheureusement, dans d'autres langues, c'est le contraire (par exemple, les guillemets simples nécessitent Shift + quelque chose tandis que les guillemets doubles sont une seule touche). Dommage car si deux personnes avec des configurations de clavier différentes travaillent sur le même projet, l'une d'entre elles devra sacrifier quelques frappes :)
Halil Özgür

«Je suis un homme pressé» - À moins que vous n'appuyiez sur Shift et 2 (ou sur n'importe quelle autre touche) l'un après l'autre, vous ne gagnez pas de temps du tout en utilisant des guillemets simples.
Machisuji

8

Je pensais que j'ajouterais une comparaison de 1.8.7 et 1.9.2. Je les ai courus plusieurs fois. La variance était d'environ + -0,01.

require 'benchmark'
n = 1000000
Benchmark.bm do |x|
  x.report("assign single") { n.times do; c = 'a string'; end}
  x.report("assign double") { n.times do; c = "a string"; end}
  x.report("assign interp") { n.times do; c = "a #{n} string"; end}
  x.report("concat single") { n.times do; 'a string ' + 'b string'; end}
  x.report("concat double") { n.times do; "a string " + "b string"; end}
  x.report("concat interp") { n.times do; "a #{n} string " + "b #{n} string"; end}
end

ruby 1.8.7 (niveau de correctif 302 du 16/08/2010) [x86_64-linux]

assign single  0.180000   0.000000   0.180000 (  0.187233)
assign double  0.180000   0.000000   0.180000 (  0.187566)
assign interp  0.880000   0.000000   0.880000 (  0.877584)
concat single  0.550000   0.020000   0.570000 (  0.567285)
concat double  0.570000   0.000000   0.570000 (  0.570644)
concat interp  1.800000   0.010000   1.810000 (  1.816955)

ruby 1.9.2p0 (révision 29036 du 18/08/2010) [x86_64-linux]

  user          system      total      real
assign single  0.140000   0.000000   0.140000 (  0.144076)
assign double  0.130000   0.000000   0.130000 (  0.142316)
assign interp  0.650000   0.000000   0.650000 (  0.656088)
concat single  0.370000   0.000000   0.370000 (  0.370663)
concat double  0.370000   0.000000   0.370000 (  0.370076)
concat interp  1.420000   0.000000   1.420000 (  1.412210)

Interp doit faire des conversions de nombre en chaîne. Voir gist.github.com/810463 .
Brian Deterling le

Voir ma réponse pour savoir pourquoi vous obtenez ces chiffres.
Marc-André Lafortune

Bon point sur l'Interp. Je viens de copier la réponse précédente comme base de la mienne. Cela m'apprendra.
PhilT

3

Il n'y a pas de différence significative dans les deux sens. Il faudrait que ce soit énorme pour que cela compte.

À l'exception des moments où vous êtes sûr qu'il y a un problème réel avec le timing, optimisez la maintenabilité du programmeur.

Les coûts du temps machine sont très très faibles. Le coût du temps du programmeur pour écrire du code et le maintenir est énorme.

À quoi sert une optimisation pour gagner des secondes, voire des minutes d'exécution sur des milliers d'exécutions si cela signifie que le code est plus difficile à maintenir?

Choisissez avec un style et respectez-le, mais ne choisissez pas ce style en fonction de millisecondes d'exécution statistiquement insignifiantes.


1

Je pensais moi aussi que les chaînes entre guillemets pourraient être plus rapides à analyser pour Ruby. Cela ne semble pas être le cas.

Quoi qu'il en soit, je pense que le point de repère ci-dessus mesure la mauvaise chose, cependant. Il va de soi que l'une ou l'autre des versions sera analysée dans les mêmes représentations de chaînes internes afin d'obtenir la réponse quant à la plus rapide à analyser, nous ne devrions pas mesurer les performances avec des variables de chaîne, mais plutôt la vitesse d'analyse des chaînes de Ruby.

generate.rb: 
10000.times do
  ('a'..'z').to_a.each {|v| print "#{v}='This is a test string.'\n" }
end

#Generate sample ruby code with lots of strings to parse
$ ruby generate.rb > single_q.rb
#Get the double quote version
$ tr \' \" < single_q.rb > double_q.rb

#Compare execution times
$ time ruby single_q.rb 

real    0m0.978s
user    0m0.920s
sys     0m0.048s
$ time ruby double_q.rb 

real    0m0.994s
user    0m0.940s
sys     0m0.044s

Les courses répétées ne semblent pas faire beaucoup de différence. Il faut toujours à peu près le même temps pour analyser l'une ou l'autre version de la chaîne.


0

C'est certainement possible en fonction de l'implémentation, mais la partie numérisation de l'interpréteur ne doit regarder chaque caractère qu'une seule fois. Il aura juste besoin d'un état supplémentaire (ou d'un ensemble d'états possible) et de transitions pour gérer les blocs # {}.

Dans un scanner basé sur une table, il ne s'agira qu'une seule recherche pour déterminer la transition, et se produira de toute façon pour chaque personnage.

Lorsque l'analyseur obtient la sortie du scanner, on sait déjà qu'il devra évaluer le code dans le bloc. Ainsi, la surcharge n'est en réalité que la surcharge de mémoire dans le scanner / analyseur pour gérer le bloc # {}, que vous payez dans les deux cas.

À moins que je manque quelque chose (ou que je me souvienne mal des détails de construction du compilateur), ce qui est également certainement possible :)


0
~ > ruby -v   
jruby 1.6.7 (ruby-1.8.7-p357) (2012-02-22 3e82bc8) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_37) [darwin-x86_64-java]
~ > cat qu.rb 
require 'benchmark'

n = 1000000
Benchmark.bm do |x|
  x.report("assign single") { n.times do; c = 'a string'; end}
  x.report("assign double") { n.times do; c = "a string"; end}
  x.report("concat single") { n.times do; 'a string ' + 'b string'; end}
  x.report("concat double") { n.times do; "a string " + "b string"; end}
end
~ > ruby qu.rb
      user     system      total        real
assign single  0.186000   0.000000   0.186000 (  0.151000)
assign double  0.062000   0.000000   0.062000 (  0.062000)
concat single  0.156000   0.000000   0.156000 (  0.156000)
concat double  0.124000   0.000000   0.124000 (  0.124000)

0

Il y en a un que vous avez tous manqué.

ICI doc

essaye ça

require 'benchmark'
mark = <<EOS
a string
EOS
n = 1000000
Benchmark.bm do |x|
  x.report("assign here doc") {n.times do;  mark; end}
end

Cela m'a donné

`asign here doc  0.141000   0.000000   0.141000 (  0.140625)`

et

'concat single quotes  1.813000   0.000000   1.813000 (  1.843750)'
'concat double quotes  1.812000   0.000000   1.812000 (  1.828125)'

donc c'est certainement mieux que concat et écrire tous ces put.

J'aimerais voir Ruby enseigné davantage dans le sens d'un langage de manipulation de documents.

Après tout, ne faisons-nous pas vraiment cela dans Rails, Sinatra et en exécutant des tests?


0

J'ai modifié la réponse de Tim Snowhite.

require 'benchmark'
n = 1000000
attr_accessor = :a_str_single, :b_str_single, :a_str_double, :b_str_double
@a_str_single = 'a string'
@b_str_single = 'b string'
@a_str_double = "a string"
@b_str_double = "b string"
@did_print = false
def reset!
    @a_str_single = 'a string'
    @b_str_single = 'b string'
    @a_str_double = "a string"
    @b_str_double = "b string"
end
Benchmark.bm do |x|
    x.report('assign single       ') { n.times do; c = 'a string'; end}
    x.report('assign via << single') { c =''; n.times do; c << 'a string'; end}
    x.report('assign double       ') { n.times do; c = "a string"; end}
    x.report('assing interp       ') { n.times do; c = "a string #{'b string'}"; end}
    x.report('concat single       ') { n.times do; 'a string ' + 'b string'; end}
    x.report('concat double       ') { n.times do; "a string " + "b string"; end}
    x.report('concat single interp') { n.times do; "#{@a_str_single}#{@b_str_single}"; end}
    x.report('concat single <<    ') { n.times do; @a_str_single << @b_str_single; end}
    reset!
    # unless @did_print
    #   @did_print = true
    #   puts @a_str_single.length 
    #   puts " a_str_single: #{@a_str_single} , b_str_single: #{@b_str_single} !!"
    # end
    x.report('concat double interp') { n.times do; "#{@a_str_double}#{@b_str_double}"; end}
    x.report('concat double <<    ') { n.times do; @a_str_double << @b_str_double; end}
end

Résultats:

jruby 1.7.4 (1.9.3p392) 2013-05-16 2390d3b on Java HotSpot(TM) 64-Bit Server VM 1.7.0_10-b18 [darwin-x86_64]
       user     system      total        real
assign single         0.220000   0.010000   0.230000 (  0.108000)
assign via << single  0.280000   0.010000   0.290000 (  0.138000)
assign double         0.050000   0.000000   0.050000 (  0.047000)
assing interp         0.100000   0.010000   0.110000 (  0.056000)
concat single         0.230000   0.010000   0.240000 (  0.159000)
concat double         0.150000   0.010000   0.160000 (  0.101000)
concat single interp  0.170000   0.000000   0.170000 (  0.121000)
concat single <<      0.100000   0.000000   0.100000 (  0.076000)
concat double interp  0.160000   0.000000   0.160000 (  0.108000)
concat double <<      0.100000   0.000000   0.100000 (  0.074000)

ruby 1.9.3p429 (2013-05-15 revision 40747) [x86_64-darwin12.4.0]
       user     system      total        real
assign single         0.100000   0.000000   0.100000 (  0.103326)
assign via << single  0.160000   0.000000   0.160000 (  0.163442)
assign double         0.100000   0.000000   0.100000 (  0.102212)
assing interp         0.110000   0.000000   0.110000 (  0.104671)
concat single         0.240000   0.000000   0.240000 (  0.242592)
concat double         0.250000   0.000000   0.250000 (  0.244666)
concat single interp  0.180000   0.000000   0.180000 (  0.182263)
concat single <<      0.120000   0.000000   0.120000 (  0.126582)
concat double interp  0.180000   0.000000   0.180000 (  0.181035)
concat double <<      0.130000   0.010000   0.140000 (  0.128731)

0

J'ai essayé ce qui suit:

def measure(t)
  single_measures = []
  double_measures = []
  double_quoted_string = ""
  single_quoted_string = ''
  single_quoted = 0
  double_quoted = 0

  t.times do |i|
    t1 = Time.now
    single_quoted_string << 'a'
    t1 = Time.now - t1
    single_measures << t1

    t2 = Time.now
    double_quoted_string << "a"
    t2 = Time.now - t2
    double_measures << t2

    if t1 > t2 
      single_quoted += 1
    else
      double_quoted += 1
    end
  end
  puts "Single quoted did took longer in #{((single_quoted.to_f/t.to_f) * 100).round(2)} percent of the cases"
  puts "Double quoted did took longer in #{((double_quoted.to_f/t.to_f) * 100).round(2)} percent of the cases"

  single_measures_avg = single_measures.inject{ |sum, el| sum + el }.to_f / t
  double_measures_avg = double_measures.inject{ |sum, el| sum + el }.to_f / t
  puts "Single did took an average of #{single_measures_avg} seconds"
  puts "Double did took an average of #{double_measures_avg} seconds"
    puts "\n"
end
both = 10.times do |i|
  measure(1000000)
end

Et ce sont les sorties:

1.

Single quoted did took longer in 32.33 percent of the cases
Double quoted did took longer in 67.67 percent of the cases
Single did took an average of 5.032084099982639e-07 seconds
Double did took an average of 5.171539549983464e-07 seconds

2.

Single quoted did took longer in 26.9 percent of the cases
Double quoted did took longer in 73.1 percent of the cases
Single did took an average of 4.998066229983696e-07 seconds
Double did took an average of 5.223457359986066e-07 seconds

3.

Single quoted did took longer in 26.44 percent of the cases
Double quoted did took longer in 73.56 percent of the cases
Single did took an average of 4.97640888998877e-07 seconds
Double did took an average of 5.132918459987151e-07 seconds

4.

Single quoted did took longer in 26.57 percent of the cases
Double quoted did took longer in 73.43 percent of the cases
Single did took an average of 5.017136069985988e-07 seconds
Double did took an average of 5.004514459988143e-07 seconds

5.

Single quoted did took longer in 26.03 percent of the cases
Double quoted did took longer in 73.97 percent of the cases
Single did took an average of 5.059069689983285e-07 seconds
Double did took an average of 5.028807639983705e-07 seconds

6.

Single quoted did took longer in 25.78 percent of the cases
Double quoted did took longer in 74.22 percent of the cases
Single did took an average of 5.107472039991399e-07 seconds
Double did took an average of 5.216212339990241e-07 seconds

7.

Single quoted did took longer in 26.48 percent of the cases
Double quoted did took longer in 73.52 percent of the cases
Single did took an average of 5.082368429989468e-07 seconds
Double did took an average of 5.076817109989933e-07 seconds

8.

Single quoted did took longer in 25.97 percent of the cases
Double quoted did took longer in 74.03 percent of the cases
Single did took an average of 5.077162969990005e-07 seconds
Double did took an average of 5.108381859991112e-07 seconds

9.

Single quoted did took longer in 26.28 percent of the cases
Double quoted did took longer in 73.72 percent of the cases
Single did took an average of 5.148080479983138e-07 seconds
Double did took an average of 5.165793929982176e-07 seconds

dix.

Single quoted did took longer in 25.03 percent of the cases
Double quoted did took longer in 74.97 percent of the cases
Single did took an average of 5.227828659989748e-07 seconds
Double did took an average of 5.218296609988378e-07 seconds

Si je ne me suis pas trompé, il me semble que les deux prennent à peu près le même temps, même si les guillemets simples sont légèrement plus rapides dans la plupart des cas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.