Tôi có chương trình gốc C++ chạy chậm hơn 20 lần khi khởi động với Debug (F5) nhưng chạy ở tốc độ bình thường khi sử dụng bắt đầu mà không gỡ lỗi (Ctrl + F5).Ứng dụng Visual Studio chạy cực kỳ chậm với gỡ lỗi
Việc tôi sử dụng bản dựng gỡ lỗi hoặc bản phát hành không quan trọng. Ngoài ra nếu tôi sử dụng Windbg chương trình là một cường độ chậm hơn.
Có một số cài đặt tôi đã chọn sai hay gì đó không?
Đặt biến môi trường _NO_DEBUG_HEAP đến 1 (như đã thấy trên http://preshing.com/20110717/the-windows-heap-is-slow-when-launched-from-the-debugger)
này có thể được thực hiện từ bên trong Visual, quá.
Bây giờ đây chỉ là một cách giải quyết khác, tôi rất tò mò muốn biết cách cấu trúc lại chương trình bị loại vấn đề này. Bạn có nhiều std :: map's, shared_ptr, hoặc bất kỳ indirections lớn khác bởi bất kỳ cơ hội?
Tôi không thể xác nhận nếu điều này thực sự là trường hợp trong chương trình của tôi nhưng nó thực sự âm thanh như vấn đề của tôi. – plaisthos
Gỡ lỗi Visual C++ đi kèm với rất nhiều và nhiều chi phí, đặc biệt là trong STL. Thử không xác định _DEBUG và xác định NDEBUG.
Tuy nhiên, điều đó không trả lời câu hỏi của OP - nó vẫn là một bản dựng lỗi, chỉ cần chạy bên ngoài IDE. Chẩn đoán STL sẽ vẫn chạy. –
Có một số điều khác nhau nếu bạn chạy bản dựng gỡ lỗi bên ngoài IDE. Một là IDE mất một thời gian để tải các biểu tượng, và nếu bạn phụ thuộc vào rất nhiều thư viện thì thời gian khởi động đó có thể đáng kể. Nếu bạn đang sử dụng một máy chủ biểu tượng (bao gồm cả máy chủ biểu tượng công cộng microsoft) thì điều này có thể thêm vào thời gian khởi động, vì vậy hãy đảm bảo bạn có bộ nhớ cache biểu tượng cục bộ trong biến số _NT_SYMBOL_PATH nếu trường hợp đó xảy ra.
Cũng IDE chạy với heap gỡ lỗi được kích hoạt, nhưng tôi không nghĩ rằng điều này xảy ra nếu bạn chạy bên ngoài IDE.
Tôi đang sử dụng máy chủ biểu tượng. Nhưng tôi không nói về thời gian khởi động nhưng thời gian chương trình sử dụng để thực sự chạy. Tôi đã chẩn đoán về với std :: cout, trong đó có khoảng một lần mỗi giây với Ctrl + F5 và một evvery 30 hoặc lâu hơn khi chạy với F5. Tôi nghĩ rằng việc gỡ lỗi đống phụ thuộc vào macro _DEBUG sẽ kiểm tra đống trong cả hai trường hợp. – plaisthos
Bạn có bất kỳ điểm ngắt điều kiện hoặc điểm truy cập nào được đặt không? Đây có thể làm chậm thực hiện xuống theo thứ tự độ lớn. Thử tắt tạm thời tất cả các điểm ngắt. –
Không may, tôi không có bất kỳ điều gì như vậy. Có thể đã quá dễ dàng :) – plaisthos
Điều này tất nhiên không phải do biểu tượng _DEBUG xác định hoặc biên dịch mã trong cấu hình gỡ lỗi. Mã gỡ lỗi bổ sung chạy hay không trình gỡ lỗi được đính kèm vào chương trình.
Trình gỡ lỗi không bình thường ảnh hưởng đến việc thực thi mã, nó vẫn nằm ngoài đường dẫn bằng cách gọi WaitForDebugEvent. Mà khối nó, cho đến khi hệ điều hành nói với nó rằng một cái gì đó đáng chú ý xảy ra. Điều đó có thể kích hoạt một loạt các mã trong trình gỡ rối có thể làm chậm chương trình của bạn. Bạn có thể xem các sự kiện được liệt kê trong tài liệu cấu trúc DEBUG_EVENT.
chú thích cho họ một chút ngoài tài liệu: các bước gỡ rối trong và có thể làm chậm chương trình của bạn khi:
Các tải chương trình hoặc unloads một DLL. Rất nhiều thứ xảy ra trong quá trình tải, trình gỡ rối đi săn tìm một tệp biểu tượng gỡ lỗi (.pdb). Nó có thể liên lạc với một máy chủ biểu tượng để tải xuống. Bất kỳ điểm ngắt nào được đặt trong mã nguồn DLL sẽ được kích hoạt. Điều này có thể khá chậm, nhưng hiệu quả là tạm thời và thường chỉ làm chậm quá trình khởi động. Bạn có thể thấy thông báo tải/dỡ trong cửa sổ Output.
Chương trình tăng ngoại lệ. Điều này kích hoạt trình gỡ lỗi tại thời điểm ngoại lệ được nêu ra, "thông báo cơ hội đầu tiên". Điều này có thể rất hữu ích, bạn có thể sử dụng hộp kiểm Debug + Exception, Thrown để làm cho trình gỡ lỗi dừng lại khi ngoại lệ được nâng lên. Bạn có thể thấy thông báo thông báo trong cửa sổ Output. Mã số này làm làm chậm và bắt các ngoại lệ rất nhiều và có khả năng là nguồn gốc của sự chậm lại của bạn. Không bao giờ sử dụng ngoại lệ cho điều khiển luồng.
Chủ đề bắt đầu chạy hoặc kết thúc. Một lần nữa, một thông báo thông báo được in ra cửa sổ Output. Bạn sẽ phải tạo một số lô hàng lô để làm cho chương trình của bạn chậm lại.
Khi chương trình của bạn sử dụng OutputDebugString() cho mục đích truy tìm. Hiển thị trong cửa sổ Output. Một ứng cử viên tốt cho một chậm lại, sản lượng rơi vào xô bit nếu không có trình sửa lỗi được đính kèm.Bạn không nên gặp bất kỳ sự cố nào khi chẩn đoán điều này là nguyên nhân, tác dụng phụ rõ ràng là nhìn thấy một số lô của thư trong cửa sổ Kết quả.
Khi chương trình truy cập điểm ngắt. Không có nhiều lý do để bị bối rối bởi điều đó. Nhưng bạn có thể thiết lập các điểm ngắt làm chậm chương trình rất nhiều nhưng không gây ra lỗi ngắt. Đặc biệt là Điểm ngắt có điều kiện, Bộ đếm truy cập, Bộ lọc và hoạt động Khi lần truy cập sẽ chậm. Sử dụng Debug + Windows + Breakpoints để xem lại các điểm ngắt được xác định.
Sử dụng Prism ở đây để tải nhiều mô-đun sau khi khởi động. Có vẻ là nguyên nhân, vâng. –
Không ai đề cập đến việc đóng các cửa sổ nguồn không sử dụng.
Sau khi đóng hơn 20 cửa sổ không sử dụng, bước gỡ lỗi nguồn đi từ ~ 5s trở xuống ~ .2s. Dự án này bất thường chậm tải một DLL động và rằng DLL cũng là một trong những bước được thông qua (và có cửa sổ nguồn mở) vì vậy nó có vẻ như có khả năng liên quan. Tuy nhiên, đây là C# (dòng tiêu đề và thẻ không cụ thể).
Khi quá trình được tạo trong trình gỡ lỗi, hệ điều hành theo mặc định sẽ sử dụng heap gỡ lỗi. Heap gỡ lỗi thực hiện xác minh nhiều hơn bộ nhớ của bạn, đặc biệt là tại de-alloc.
Có một số tùy chọn có thể để vô hiệu hóa việc sử dụng Debug Heap:
Đính kèm để quá trình này ngay sau khi khởi động. Điều này sẽ cho phép bạn tăng tốc độ hiệu suất trong chế độ gỡ lỗi một cách cố ý và nhận thức đầy đủ về chế độ mà bạn đang chạy.
Thêm cài đặt biến môi trường _NO_DEBUG_HEAP = 1.
Điều này có thể được đặt trên toàn cầu cho máy hoặc cho một trường hợp cụ thể của Visual Studio.a. Trên toàn cầu, bạn sẽ thiết lập một biến môi trường thông qua Bảng điều khiển → Hệ thống → Cài đặt hệ thống nâng cao → Biến môi trường và có thêm biến _NO_DEBUG_HEAP = 1.
Lưu ý: Điều này sẽ ảnh hưởng đến mọi ứng dụng bạn gỡ lỗi.b. Đối với một thể hiện của Visual Studio bạn có thể mở một dấu nhắc lệnh, thiết lập biến môi trường _NO_DEBUG_HEAP = 1 và sau đó mở studio trực quan từ bên trong dấu nhắc lệnh đó. Điều này sẽ chỉ ảnh hưởng đến các quá trình được tạo từ trường hợp đó của Visual Studio sẽ kế thừa biến môi trường .
Thêm hành vi của trình gỡ lỗi, điều này có thể cho VS2015. Có 2 cách để ghi đè điều này:
a.Để sửa đổi cho một dự án cụ thể, đi đến thuộc tính dự án Thuộc tính cấu hình → Gỡ lỗi và thay đổi thuộc tính Môi trường _NO_DEBUG_HEAP thành 1
b. Để sửa đổi cho mọi dự án trong Visual Studio, đi đến Công cụ → Tùy chọn → Gỡ lỗi và chọn tùy chọn: “Bật trình cấp phát heap gỡ lỗi Windows (Chỉ dành cho bản địa)”.
Lưu ý: f biến môi trường _NO_DEBUG_HEAP được đề cập trong 'a' được đặt ở cấp dự án, nó sẽ ghi đè cài đặt chung này.
Đối với tôi sự khác biệt về hiệu năng giữa chế độ gỡ lỗi và giải phóng chế độ là một yếu tố về . Sau khi một số đào, nó xuất hiện một số điều góp phần vào sự khác biệt trong hiệu suất, nhưng có một tùy chọn biên dịch mà quadruples hiệu suất gỡ lỗi của tôi gần như miễn phí.
Cụ thể, thay đổi /ZI thành /Zi. Để biết mô tả, hãy xem de msdn page.
Tôi không sử dụng tính năng chỉnh sửa và tiếp tục.
Gỡ lỗi thêm nhiều chi phí cho chương trình. Tại sao bạn giả định mọi thứ sai? – Oded
Gỡ lỗi không được thêm quá nhiều chi phí. Sự khác biệt giữa một trình gỡ rối được đính kèm và không được đính kèm không phải là sự khác biệt chút nào. – plaisthos