Nhận xét có ảnh hưởng đến hiệu suất của Perl không?

Question

Tôi đang tối ưu hóa một số mã Perl thường xuyên (một lần mỗi ngày cho mỗi tệp).

Làm các nhận xét làm chậm tập lệnh Perl xuống? Các thử nghiệm của tôi nghiêng về phía không:

use Benchmark; 
timethese(20000000, { 
    'comments' => '$b=1; 
# comment ... (100 times) 
', 'nocomments' => '$b=1;'}); 

Cung cấp nhiều giá trị giống hệt nhau (ngoài tiếng ồn).

Benchmark: timing 10000000 iterations of comments, nocomments... 
    comments: 1 wallclock secs (0.53 usr + 0.00 sys = 0.53 CPU) @ 18832391.71/s (n=10000000) 
nocomments: 0 wallclock secs (0.44 usr + 0.00 sys = 0.44 CPU) @ 22935779.82/s (n=10000000) 

Benchmark: timing 20000000 iterations of comments, nocomments... 
    comments: 0 wallclock secs (0.86 usr + -0.01 sys = 0.84 CPU) @ 23696682.46/s (n=20000000) 
nocomments: 1 wallclock secs (0.90 usr + 0.00 sys = 0.90 CPU) @ 22099447.51/s (n=20000000) 

Tôi nhận được kết quả tương tự nếu tôi chạy các nhận xét và không có nhận xét phiên bản dưới dạng tập lệnh Perl riêng biệt.

Dường như có vẻ phản trực giác, nếu không có gì khác, người phiên dịch cần phải đọc nhận xét vào bộ nhớ mỗi lần.

Answer 1

Perl là ngôn ngữ được biên dịch kịp thời, vì vậy nhận xét và POD không ảnh hưởng đến hiệu suất thời gian chạy.

Nhận xét và POD có tác dụng nhỏ trên thời gian biên dịch, nhưng chúng dễ dàng và nhanh chóng để Perl phân tích cú pháp hầu như không thể đo lường hiệu suất đạt được. Bạn có thể thấy điều này cho chính mình bằng cách sử dụng cờ -c để biên dịch.

Trên Macbook của tôi, một chương trình Perl với 2 câu lệnh và 1000 dòng gồm 70 nhận xét ký tự sẽ mất cùng một thời gian để biên dịch thành 1000 dòng nhận xét trống dưới dạng chú thích in. Hãy chắc chắn chạy từng điểm chuẩn hai lần để cho phép hệ điều hành của bạn lưu vào bộ nhớ cache tệp, nếu không thì điểm chuẩn bạn là thời gian để đọc tệp từ đĩa.

Nếu thời gian khởi động là một vấn đề đối với bạn, đó không phải do nhận xét và POD.

Answer 2

Perl biên dịch một tập lệnh và sau đó thực hiện nó. Bình luận làm chậm giai đoạn biên dịch, nhưng không có tác dụng trên pha chạy.

Answer 3

Hiệu suất thời gian chạy? Số

Phân tích cú pháp và hiệu suất lexing? Phải, tất nhiên.

Vì Perl có xu hướng phân tích cú pháp và lex khi đang di chuyển, khi đó nhận xét sẽ ảnh hưởng đến hiệu suất "khởi động".

Chúng có ảnh hưởng đến nó không? Không chắc.

Answer 4

Tôi hy vọng rằng một nhận xét sẽ chỉ được phân tích cú pháp một lần, không phải nhiều lần trong vòng lặp, vì vậy tôi nghi ngờ đó là một thử nghiệm hợp lệ.

Tôi hy vọng rằng các nhận xét sẽ làm chậm quá trình biên dịch, nhưng tôi cho rằng nó sẽ quá nhỏ để làm phiền việc xóa chúng.

Answer 5

Từ Paul Tomblins bình luận:

Không perl làm một số loại biên soạn on-the-fly? Có lẽ các bình luận bị loại bỏ sớm? -

Có Perl.

Đây là ngôn ngữ lập trình được biên dịch và biên dịch. Mã được biên dịch nhanh chóng và sau đó chạy. các bình luận thường không tạo ra bất kỳ sự khác biệt nào. Nhiều nhất nó có thể có hiệu lực là khi nó ban đầu phân tích cú pháp dòng tập tin theo dòng và biên dịch trước nó, bạn có thể thấy một sự khác biệt thứ hai nano.

Answer 6

Làm các chú thích Perl làm chậm tập lệnh xuống? Vâng, phân tích nó, vâng. Thực hiện nó sau khi phân tích nó? Không. Một tập lệnh được phân tích cú pháp thường xuyên như thế nào? Chỉ một lần, vì vậy nếu bạn có một nhận xét trong vòng lặp, nhận xét sẽ bị loại bỏ bởi các phân tích một lần, trước khi tập lệnh chạy, khi nó bắt đầu chạy, nhận xét đã biến mất (và tập lệnh không được lưu trữ dưới dạng tập lệnh nội bộ theo Perl), do đó không có vấn đề bao nhiêu lần lặp cho lặp đi lặp lại, bình luận sẽ không có một ảnh hưởng. Trình phân tích cú pháp có thể bỏ qua nhanh các nhận xét như thế nào? Cách Perl ý kiến ​​được thực hiện, rất nhanh, do đó tôi nghi ngờ bạn sẽ nhận thấy. Bạn sẽ nhận thấy thời gian khởi động cao hơn nếu bạn có 5 dòng mã và giữa mỗi dòng 1 dòng nhận xét Mio ... nhưng khả năng là như thế nào và sử dụng chú thích nào lớn?

Answer 7

Perl không phải là ngôn ngữ kịch bản theo cùng nghĩa là các tập lệnh hệ vỏ là. Người thông dịch không đọc từng dòng một.Việc thực hiện một chương trình Perl được thực hiện trong hai giai đoạn cơ bản: biên dịch và thời gian chạy [1]. Trong giai đoạn biên dịch mã nguồn được phân tích cú pháp và chuyển thành bytecode. Trong suốt thời gian chạy, bytecode được thực hiện trên một máy ảo.

Nhận xét sẽ làm chậm giai đoạn phân tích cú pháp nhưng sự khác biệt là không đáng kể so với thời gian cần thiết để phân tích cú pháp chính kịch bản lệnh (vốn đã rất nhỏ đối với hầu hết các chương trình). Khoảng thời gian duy nhất bạn thực sự quan tâm đến thời gian phân tích cú pháp là trong môi trường máy chủ web nơi chương trình có thể được gọi nhiều lần trong một giây. mod_perl tồn tại để giải quyết vấn đề này.

Bạn đang sử dụng Benchmark. Tốt lắm! Bạn nên tìm cách để cải thiện thuật toán - không tối ưu hóa vi mô. Devel :: DProf có thể hữu ích để tìm bất kỳ điểm nóng nào. Bạn hoàn toàn không được nhận xét dải trong một nỗ lực sai lầm để làm cho chương trình của bạn nhanh hơn. Bạn sẽ làm cho nó không thể duy trì được.

---

[1] Điều này thường được gọi là biên soạn "đúng lúc". Perl thực sự có một số giai đoạn khác như INIT và END không quan trọng ở đây.

Answer 8

Vấn đề là: tối ưu hóa tắc nghẽn. Đọc trong một tập tin bao gồm:

• mở tập tin,
• đọc trong nội dung của nó,
• đóng tập tin,
• phân tích các nội dung.

Trong số các bước này, đọc là phần nhanh nhất từ ​​trước đến nay (Tôi không chắc chắn về việc đóng, đó là syscall, nhưng bạn không phải chờ cho đến khi kết thúc). Thậm chí nếu nó là 10% của toàn bộ điều (đó là không phải là, tôi nghĩ), sau đó giảm nó bằng một nửa chỉ cho hiệu suất cải thiện 5%, với chi phí của ý kiến ​​mất tích (đó là một điều rất xấu). Đối với trình phân tích cú pháp, việc bỏ đi một dòng bắt đầu bằng # không phải là sự chậm lại hữu hình. Và sau đó, các bình luận đã biến mất, vì vậy không thể làm chậm lại được.

Bây giờ, hãy tưởng tượng rằng bạn thực sự có thể cải thiện phần "đọc trong tập lệnh" thêm 5% thông qua tước tất cả nhận xét (đó là ước tính thực sự lạc quan, xem ở trên). Làm thế nào lớn là chia sẻ của "đọc trong kịch bản" trong thời gian tiêu thụ tổng thể của kịch bản? Tất nhiên, phụ thuộc vào số lượng, nhưng vì các tập lệnh perl thường đọc ít nhất một tệp, nhiều nhất là 50%, nhưng vì tập lệnh perl thường làm điều gì đó hơn, nên ước tính trung thực sẽ làm giảm điều này trong phạm vi 1%. Vì vậy, cải thiện hiệu quả mong đợi bằng cách xóa tất cả các nhận xét là tạinhất (rất lạc quan) 2,5%, nhưng thực sự gần với 0,05%. Và sau đó, những nơi nó thực sự cung cấp hơn 1% đã nhanh chóng vì chúng hầu như không có gì, vì vậy bạn lại một lần nữa tối ưu hóa ở sai điểm.

Kết thúc, tối ưu hóa tắc nghẽn.

Answer 9

Mô-đun điểm chuẩn là vô ích trong trường hợp này. Nó chỉ đo thời gian để chạy mã hơn và hơn nữa. Vì mã của bạn không thực sự làm bất cứ điều gì, hầu hết nó được tối ưu hóa nó đi. Đó là lý do tại sao bạn thấy nó chạy 22 triệu lần một giây.

Tôi có gần như toàn bộ chương về điều này trong Mastering Perl. Lỗi đo lường trong kỹ thuật Điểm chuẩn là khoảng 7%. Số điểm chuẩn của bạn tốt trong số đó, vì vậy hầu như không có sự khác biệt.