Per cose semplici è meglio usare la funzione translate sul presupposto che sia meno intensivo della CPU o sia regexp_replace la strada da percorrere?Prestazioni di regexp_replace vs translate in Oracle?
Questa domanda esce dalla How can I replace brackets to hyphens within Oracle REGEXP_REPLACE function?
Per SQL, ho provato questo con il seguente script:
set timing on
select sum(length(x)) from (
select translate('(<FIO>)', '()[]', '----') x
from (
select *
from dual
connect by level <= 2000000
)
);
select sum(length(x)) from (
select regexp_replace('[(<FIO>)]', '[\(\)\[]|\]', '-', 1, 0) x
from (
select *
from dual
connect by level <= 2000000
)
);
e ha scoperto che le prestazioni di translate e regexp_replace erano quasi sempre gli stessi, ma potrebbe che il costo delle altre operazioni stia schiacciando il costo delle funzioni che sto provando a testare.
Poi, ho provato una versione PL/SQL:
set timing on
declare
x varchar2(100);
begin
for i in 1..2500000 loop
x := translate('(<FIO>)', '()[]', '----');
end loop;
end;
/
declare
x varchar2(100);
begin
for i in 1..2500000 loop
x := regexp_replace('[(<FIO>)]', '[\(\)\[]|\]', '-', 1, 0);
end loop;
end;
/
Ecco la versione translate prende poco meno di 10 secondi, mentre la versione regexp_replace circa 0,2 secondi - circa 2 ordini di grandezza più veloci
Sulla base di questo risultato, userò le espressioni regolari molto più spesso nel mio codice critico delle prestazioni - sia SQL che PL/SQL.
Penso che tu stia eseguendo una semplice ottimizzazione. L'espressione regexp è così costosa da calcolare che il risultato è memorizzato nella cache nella speranza che verrà riutilizzato in futuro. Se effettivamente usi stringhe distinte per convertire, vedrai che la traduzione modesta è naturalmente più veloce perché è la sua funzione specializzata.
Ecco il mio esempio, in esecuzione su 11.1.0.7.0:
SQL> DECLARE
2 TYPE t IS TABLE OF VARCHAR2(4000);
3 l t;
4 l_level NUMBER := 1000;
5 l_time TIMESTAMP;
6 l_char VARCHAR2(4000);
7 BEGIN
8 -- init
9 EXECUTE IMMEDIATE 'ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL=2';
10 SELECT dbms_random.STRING('p', 2000)
11 BULK COLLECT
12 INTO l FROM dual
13 CONNECT BY LEVEL <= l_level;
14 -- regex
15 l_time := systimestamp;
16 FOR i IN 1 .. l.count LOOP
17 l_char := regexp_replace(l(i), '[]()[]', '-', 1, 0);
18 END LOOP;
19 dbms_output.put_line('regex :' || (systimestamp - l_time));
20 -- tranlate
21 l_time := systimestamp;
22 FOR i IN 1 .. l.count LOOP
23 l_char := translate(l(i), '()[]', '----');
24 END LOOP;
25 dbms_output.put_line('translate :' || (systimestamp - l_time));
26 END;
27/
regex :+000000000 00:00:00.979305000
translate :+000000000 00:00:00.238773000
PL/SQL procedure successfully completed
su 11.2.0.3.0:
regex :+000000000 00:00:00.617290000
translate :+000000000 00:00:00.138205000
Conclusione: In generale, ho il sospetto translate vincerà.
Penso che tu stia saltando a una conclusione un po 'frettolosamente qui :) Se ci pensi, solo l'ottimizzazione della cache può spiegare questa grandezza della differenza in runtime. In un mondo reale, non si può convertire la stessa stringa più e più volte sospetto. –
Tuttavia, è interessante vedere che in alcuni casi 'regexp' ** è più veloce ** di' translate' :) –
Su 10g Trovo che REGEXP_ sia attendibilmente uno o due ordini di grandezza più lento dei loro analoghi non-REGEXP (quando facendo abbastanza di qualcosa per misurare la differenza). Tuttavia, 10g è stata la prima versione con funzioni regex incorporate e mi sarei aspettato che Oracle avesse apportato alcune modifiche significative per 11g. – APC