2010-06-02 38 views
5

Tôi có một chương trình tôi muốn cấu hình với gprof. Vấn đề (dường như) là nó sử dụng ổ cắm. Vì vậy, tôi nhận được những thông tin như sau:Sử dụng gprof với ổ cắm

::select(): Interrupted system call 

Tôi đã gặp sự cố này một lúc, đã bỏ cuộc và tiếp tục. Nhưng tôi thực sự muốn có thể cấu hình mã của tôi, sử dụng gprof nếu có thể. Tôi có thể làm gì? Có một tùy chọn gprof tôi đang thiếu? Một lựa chọn ổ cắm? Gprof có hoàn toàn vô dụng khi có các loại cuộc gọi hệ thống này không? Nếu vậy, liệu có một sự thay thế khả thi?

EDIT: Hệ điều hành:

  • Linux 2.6 (x64)
  • GCC 4.4.1
  • gprof 2,19
+0

Tôi nghĩ rằng bạn cũng nên đề cập đến nền tảng của mình: OS, trình biên dịch, phiên bản gprof, v.v. –

+2

tôi tìm thấy bài viết này: có thể là một số cách sử dụng: http://unix.derkeiler.com/Newsgroups/comp.unix .programmer/2004-03/0938.html – LoudNPossiblyWrong

+0

Bạn đã thử sử dụng valgrind/kcachegrind cho tiểu sử chưa? Tôi thích nó để gprof. –

Trả lời

5

Mã ổ cắm cần phải xử lý hệ thống bị gián đoạn gọi bất kể profiler, nhưng theo profiler nó không thể tránh khỏi. Điều này có nghĩa là có mã như thế.

if (errno == EINTR) { ... 

sau mỗi lần gọi hệ thống.

Hãy xem, ví dụ: here cho nền.

+0

Tuyệt vời, cảm ơn. Theo dõi: http://stackoverflow.com/questions/2958114/handling-eintr-with-goto –

1

gprof (here's the paper) là đáng tin cậy, nhưng nó only was ever intended to measure changes, và thậm chí cho điều đó, nó chỉ đo lường các vấn đề liên quan đến CPU. Quảng cáo không bao giờ được quảng cáo hữu ích cho việc tìm kiếm các sự cố định vị. Đó là một ý tưởng cho những người khác xếp chồng lên trên nó.

Cân nhắc this method.

Một lựa chọn tốt khác, nếu bạn không ngại chi tiêu một số tiền, là Zoom.

Đã thêm: Nếu tôi chỉ có thể cung cấp cho bạn một ví dụ. Giả sử bạn có một hệ thống phân cấp cuộc gọi trong đó các cuộc gọi chính Một số lần, A gọi B một số lần, B gọi C một số lần, và C đợi một số I/O bằng một ổ cắm hoặc tập tin, và đó là cơ bản tất cả chương trình. Bây giờ, giả sử thêm rằng số lần mỗi lần gọi thường trình tiếp theo giảm hơn 25% so với số lần thực sự cần thực hiện. Vì 1.25^3 là khoảng 2, điều đó có nghĩa là toàn bộ chương trình mất gấp đôi thời gian để chạy vì nó thực sự cần.

Ở nơi đầu tiên, vì tất cả thời gian được chờ đợi cho I/O gprof sẽ cho bạn biết không có gì về thời gian đó là chi tiêu, bởi vì nó chỉ nhìn vào "chạy" thời gian.

Thứ hai, giả sử (chỉ cho đối số) số đã làm đếm thời gian I/O. Nó có thể cung cấp cho bạn một đồ thị cuộc gọi, về cơ bản nói rằng mỗi thói quen mất 100% thời gian. Điều đó nói gì với bạn? Không có gì nhiều hơn bạn đã biết.

Tuy nhiên, nếu bạn lấy một số lượng nhỏ các mẫu ngăn xếp, bạn sẽ thấy trên mỗi dòng trong số đó dòng mã nơi mỗi thường trình gọi tiếp theo. Nói cách khác, nó không chỉ cung cấp cho bạn ước tính thời gian phần trăm thô, đó là chỉ cho bạn các dòng mã cụ thể tốn kém. Bạn có thể xem từng dòng mã và hỏi xem có cách nào thực hiện ít lần hơn không. Giả sử bạn làm điều này, bạn sẽ nhận được các yếu tố của 2 tăng tốc.

Mọi người có được các yếu tố lớn theo cách này. Theo kinh nghiệm của tôi, số lượng các mức cuộc gọi có thể dễ dàng từ 30 trở lên. Mọi cuộc gọi có vẻ như cần thiết, cho đến khi bạn hỏi xem có thể tránh được không. Ngay cả một số lượng nhỏ các cuộc gọi có thể tránh được cũng có thể ảnh hưởng rất lớn đến nhiều lớp đó.