C'è un miglioramento delle prestazioni nell'uso delle virgolette singole rispetto alle virgolette doppie in rubino?


126

Sai se l'uso di virgolette doppie invece di virgolette singole in ruby ​​diminuisce le prestazioni in modo significativo in ruby ​​1.8 e 1.9.

quindi se scrivo

question = 'my question'

è più veloce di

question = "my question"

Immagino che Ruby cerchi di capire se qualcosa deve essere valutato quando incontra virgolette doppie e probabilmente passa alcuni cicli a fare proprio questo.


17
Eseguilo mezzo milione di volte e vedi. È probabile che il tuo sito non ottenga abbastanza traffico per importare. L'ottimizzazione prematura generalmente non ne vale la pena.
Ceejayoz,

60
perché così tante persone si aspettano che il rubino venga utilizzato solo per la programmazione web?
johannes,

17
Non prenderei in considerazione questa ottimizzazione prematura. Più di una "best practice" poiché tornare indietro dopo che l'app è stata completata e l'ottimizzazione per singolo o doppio sarebbe un grosso mal di testa.
Omar,

7
Per me è solo stile: uso altre virgolette per stringhe "statiche" e doppie qout (o altre stringhe interpolate) in altri casi.
tig

3
@Baddie: è l'ottimizzazione prematura se stai ottimizzando un problema che non esiste.
Andy Lester,

Risposte:


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)

Nota: l'ho aggiornato per farlo funzionare con le versioni più recenti di Ruby, ho ripulito l'intestazione ed eseguito il benchmark su un sistema più veloce.

Questa risposta omette alcuni punti chiave. Vedi in particolare queste altre risposte riguardanti l'interpolazione e la ragione non v'è alcuna differenza significativa in termini di prestazioni quando si utilizzano le doppie virgolette singolo vs..


Sto interpretando i risultati correttamente? L'assegnazione tramite virgolette doppie è effettivamente più veloce di quella singola? Come può essere?
randomguy,

Apparentemente sì, anche se la differenza è minore. Quanto al perché - mi batte.
zetetico

Questo benchmark sarebbe molto più convincente se prendesse in considerazione il tempo di compilazione e il tempo di esecuzione.
no, il

9
Le differenze misurate non sono significative. Solo l'ordine (a causa della raccolta dei rifiuti) può fare la differenza. Non esiste alcuna differenza di runtime tra 'e "poiché vengono analizzati nella stessa cosa.
Marc-André Lafortune,

104

Riepilogo: nessuna differenza di velocità; questa grande guida collaborativa sullo stile di Ruby raccomanda di essere coerente. Ora uso a 'string'meno che non sia necessaria l'interpolazione (opzione A nella guida) e che mi piaccia, ma in genere vedrai più codice con "string".

Dettagli:

Teoricamente, può fare la differenza quando il tuo codice viene analizzato , ma non solo non dovresti preoccuparti del tempo di analisi in generale (trascurabile rispetto al tempo di esecuzione), non sarai in grado di trovare una differenza significativa in questo caso.

L'importante è che quando viene eseguito sarà esattamente lo stesso .

Il benchmarking mostra solo una mancanza di comprensione del funzionamento di Ruby. In entrambi i casi, le stringhe verranno analizzate in a tSTRING_CONTENT(vedere l'origine inparse.y ). In altre parole, la CPU eseguirà esattamente le stesse operazioni durante la creazione di 'string'o "string". Gli stessi identici bit cambieranno esattamente nello stesso modo. L'analisi comparativa mostrerà solo differenze non significative e dovute ad altri fattori (avvio del GC, ecc.); ricorda, non ci può essere alcuna differenza in questo caso! I micro benchmark come questi sono difficili da ottenere. Vedi la mia gemma fruityper uno strumento decente per questo.

Si noti che se esiste un'interpolazione del modulo "...#{...}...", questo viene analizzato in a tSTRING_DBEG, un gruppo di tSTRING_DVARper ciascuna espressione in #{...}e un finale tSTRING_DEND. Questo è solo se c'è interpolazione, tuttavia, che non è l'OP.

Ti suggerivo di usare le virgolette doppie ovunque (rende più semplice aggiungerlo in #{some_var}seguito), ma ora uso le virgolette singole a meno che non abbia bisogno di interpolazione \n, ecc ... Mi piace visivamente ed è leggermente più esplicito, dal momento che non c'è è necessario analizzare la stringa per vedere se contiene espressioni.


3
Sembra molto più importante della minima differenza di prestazioni. Citazioni doppie è!
Venkat D.

Grazie per avermi indicato la tua risposta. Potresti chiarire perché stai dicendo che l'analisi comparativa è fuorviante? Sono d'accordo che le differenze sono probabilmente trascurabili, ma il benchmark è in qualche modo sbagliato? (Qualcuno ha già evidenziato che #{n}farebbe la conversione numerica). Non sta mostrando le differenze nell'analisi ?.
PhilT,

1
Grazie per il collegamento alla guida di stile. Non riesco a credere di non averlo mai visto prima.
PhilT,

1
La guida di stile menzionata nella tua risposta è stata aggiornata per suggerire di adottare uno stile coerente, con virgolette singole o doppie, e indica che le stringhe con virgolette doppie sono più diffuse nella comunità di Ruby.
Philtr,

Usa virgolette doppie. La programmazione è difficile. La sintassi è intrinsecamente complessa. Le virgolette doppie non significano mai commettere errori o perdere tempo con un errore quando si rende dinamica una stringa. Con le virgolette doppie, hai una cosa in meno a cui pensare.
Kelsey Hannan,

35

Tuttavia, nessuno ha misurato la concatenazione rispetto all'interpolazione:

$ 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)

In particolare, nota assign interp = 2.62vs concat single = 3.76. Come ciliegina sulla torta, trovo anche l'interpolazione più leggibile che 'a' + var + 'b'soprattutto per quanto riguarda gli spazi.


+1. Questo è l'unico benchmark di interpolazione che confronta le mele con le mele.
Mark Thomas,

1
Il benchmarking può essere fuorviante; vedi la mia risposta per il perché. Per quanto riguarda il confronto tra concatenazione e interpolazione, dovrebbe essere ovvio che l'interpolazione non può essere più lenta della concatenazione. In ogni caso, questo non fa davvero parte della domanda!
Marc-André Lafortune,

Puoi aggiungere << a questo test?
Nick,

16

Nessuna differenza, a meno che non si stia utilizzando l' #{some_var}interpolazione di stringhe di stile. Ma ottieni il massimo delle prestazioni solo se lo fai davvero.

Modificato dall'esempio di 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

produzione

               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)

Interessante. L'interpolazione sembra un po 'più costosa. Era questo 1.8? Sarebbe bello vedere se 1.9 cambia qualcosa.
zetetico il

zetetic: sì. Questo era contro Ruby 1.8.7
madlep

1
La versione interp è sia interpolante che concatenante, oltre a convertire due volte un numero in una stringa. L'interpolazione vince se i risultati sono uguali. Vedi gist.github.com/810463 . Il vero asporto è preoccuparsi più di to_s che di virgolette singole o doppie.
Brian Deterling,

Il benchmarking di questo solo può essere fuorviante e mostra un fraintendimento di come funziona Ruby. Vedi la mia risposta
Marc-André Lafortune,

13

Le virgolette singole possono essere leggermente più veloci delle doppie virgolette perché il lexer non deve controllare i #{}marcatori di interpolazione. A seconda dell'implementazione, ecc. Si noti che questo è un costo di analisi, non un costo di esecuzione.

Detto questo, la vera domanda era se l'uso di stringhe tra virgolette "riduce le prestazioni in modo significativo", a cui la risposta è un "no" decisivo. La differenza nelle prestazioni è così incredibilmente piccola che è completamente insignificante rispetto a qualsiasi reale problema di prestazioni. Non perdere tempo.

L'interpolazione effettiva è una storia diversa, ovviamente. 'foo'sarà quasi esattamente 1 secondo più veloce di "#{sleep 1; nil}foo".


4
+1 per aver notato che il costo è in fase di compilazione e non in fase di esecuzione, quindi le risposte basate su benchmark altamente votate sopra sono fuorvianti.
no, il

"questo è un costo di analisi, non un costo di esecuzione". è la frase chiave.
Tin Man,

9

Le virgolette doppie richiedono il doppio del numero di tasti per scrivere rispetto alle virgolette singole. Ho sempre fretta. Uso virgolette singole. :) E sì, lo considero un "miglioramento delle prestazioni". :)


Perché le doppie virgolette richiederebbero il doppio dei tasti premuti? Sono entrambi rappresentati da una singola chiave. Inoltre, molti IDE aggiungono automaticamente le virgolette di chiusura.
Matt Dressel,

3
Anche se l'IDE chiude automaticamente la virgoletta, le virgolette doppie richiedono ancora il 100% di avvertimenti in più. ;-)
Clint Pachl,

Matt Dressel: le virgolette doppie richiedono il doppio del numero di tasti premuti perché è necessario premere anche il tasto Maiusc. Oh: :) nel caso lo avessi perso nel mio commento originale. :) Le chiavi con filo richiedono più sforzo e probabilmente, più tempo, per l'esecuzione. :)
aqn

1
A volte seguo questo consiglio per pigrizia. Ma sfortunatamente in alcune altre lingue, è l'opposto (ad esempio le virgolette singole richiedono Shift + qualcosa mentre le virgolette doppie sono una singola sequenza di tasti). Peccato perché se due persone con layout di tastiera diversi lavorano allo stesso progetto, uno di loro dovrà sacrificare alcuni tasti :)
Halil Özgür

"Sono un uomo di fretta" - A meno che non si prema Maiusc e 2 (o quale altro tasto sia) uno dopo l'altro, non si risparmia affatto tempo usando le virgolette singole.
Machisuji,

8

Ho pensato di aggiungere un confronto tra 1.8.7 e 1.9.2. Li ho eseguiti alcune volte. La varianza era di circa + -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 (2010-08-16 patchlevel 302) [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 (revisione 18-08-2010 29036) [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 deve fare il numero per mettere in stringa le conversioni. Vedi gist.github.com/810463 .
Brian Deterling,

Vedi la mia risposta sul perché ottieni questi numeri.
Marc-André Lafortune,

Buon punto sull'Interp. Avevo appena copiato la risposta precedente come base per la mia. Questo mi insegnerà.
PhilT,

3

Non vi è alcuna differenza significativa in entrambe le direzioni. Dovrebbe essere enorme per essere importante.

Fatta eccezione per le volte in cui si è certi che si sia verificato un problema con i tempi, ottimizzare la manutenibilità del programmatore.

I costi del tempo della macchina sono molto piccoli. I costi del tempo del programmatore per scrivere codice e mantenerlo sono enormi.

A che serve un'ottimizzazione per risparmiare secondi, anche minuti di runtime su migliaia di esecuzioni se ciò significa che il codice è più difficile da mantenere?

Scegli con uno stile e mantienilo, ma non scegliere quello stile basato su millisecondi statisticamente insignificanti di runtime.


1

Anch'io pensavo che le stringhe a virgoletta singola potessero essere più veloci da analizzare per Ruby. Non sembra essere il caso.

Comunque, penso che il benchmark sopra stia misurando la cosa sbagliata, comunque. È ovvio che entrambe le versioni verranno analizzate nelle stesse rappresentazioni di stringhe interne in modo da ottenere la risposta su quale sia più veloce da analizzare, non dovremmo misurare le prestazioni con le variabili di stringa, ma piuttosto la velocità di Ruby di analizzare le stringhe.

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

Le corse ripetute non sembrano fare molta differenza. Prende ancora più o meno lo stesso tempo per analizzare entrambe le versioni della stringa.


0

È certamente possibile a seconda dell'implementazione, ma la parte di scansione dell'interprete dovrebbe guardare ogni personaggio una sola volta. Sarà necessario solo uno stato aggiuntivo (o una possibile serie di stati) e transizioni per gestire i blocchi # {}.

In uno scanner basato su tabella si tratterà di una singola ricerca per determinare la transizione e accadrà comunque per ciascun personaggio.

Quando il parser ottiene l'output dello scanner, è già noto che dovrà valutare il codice nel blocco. Quindi l'overhead è solo l'overhead di memoria nello scanner / parser per gestire il blocco # {}, che si paga in entrambi i modi.

A meno che non mi manchi qualcosa (o i dettagli di costruzione del compilatore che non ricordano), il che è certamente possibile :)


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

Ce n'è uno che tutti avete perso.

QUI doc

prova questo

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

Mi ha dato

`asign here doc  0.141000   0.000000   0.141000 (  0.140625)`

e

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

quindi è sicuramente meglio che concaticare e scrivere tutte quelle parole.

Mi piacerebbe vedere Ruby insegnare di più sulla falsariga di un linguaggio di manipolazione dei documenti.

Dopotutto, non lo facciamo davvero in Rails, Sinatra e eseguiamo dei test?


0

Ho modificato la risposta di 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

risultati:

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

Ho provato quanto segue:

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

E questi sono gli output:

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

10.

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

Se non ho commesso errori, mi sembra che entrambi impieghino all'incirca allo stesso tempo, anche se nella maggior parte dei casi il singolo citato è leggermente più veloce.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.