Đối với SQL, tôi đã thử nghiệm điều này với các kịch bản sau đây:
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
)
);
và thấy rằng hiệu suất của translate
và regexp_replace
là hầu như luôn luôn giống nhau, nhưng nó có thể được rằng chi phí của các hoạt động khác là áp đảo các chi phí của các chức năng tôi đang cố gắng để kiểm tra.
Tiếp theo, tôi đã thử một phiên bản 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;
/
Đây là phiên bản translate
chỉ mất dưới 10 giây, trong khi phiên bản regexp_replace
khoảng 0,2 giây - khoảng 2 bậc độ lớn nhanh hơn
(!)
Dựa trên kết quả này, tôi sẽ sử dụng cụm từ thông dụng thường xuyên hơn trong mã quan trọng hiệu suất của tôi - cả SQL và PL/SQL.
Nguồn
2013-04-17 11:01:52
Tôi nghĩ bạn đang nhảy đến một kết luận một chút vội vã ở đây :) Nếu bạn nghĩ về nó, chỉ tối ưu hóa bộ nhớ cache mới có thể giải thích mức độ chênh lệch này trong thời gian chạy. Trong một ví dụ thế giới thực, bạn sẽ không chuyển đổi cùng một chuỗi hơn và hơn tôi nghi ngờ. –
Tuy nhiên, thật thú vị khi thấy rằng trong một số trường hợp 'regexp' ** nhanh hơn ** so với' dịch' :) –
Vào ngày 10g, tôi thấy REGEXP_ đáng tin cậy một hoặc hai đơn hàng có cường độ chậm hơn so với các điểm tương tự không phải REGEXP của chúng (khi làm đủ thứ để đo sự khác biệt). Tuy nhiên, 10g là bản phát hành đầu tiên với các chức năng regex tích hợp và tôi đã dự kiến Oracle sẽ có một số điều chỉnh quan trọng cho 11g. – APC