Tại sao các thanh tiến độ rất không chính xác? [đóng cửa]

Máy tính và ngôn ngữ lập trình có xu hướng mang tính quyết định và có thể dự đoán được. Tuy nhiên, các thanh tiến trình có vẻ ngược lại, đặc biệt nếu hoạt động phức tạp. Ngay cả đối với các sản phẩm chuyên nghiệp đẳng cấp thế giới, một số thanh tiến trình ít làm phản ánh tiến trình thực sự của một hoạt động. Tôi đã thấy họ tăng từ 10% đến 90% trong một bước nhảy sau khi không làm gì trong 4 giờ. Tôi thậm chí đã thấy một số bước lùi, cho thấy xử lý thêm bất ngờ đã được phát hiện.

Được cho rằng có thể có các hoạt động cơ sở dữ liệu, xử lý mạng và hoạt động song song nhưng dường như điều này có thể được định lượng theo một cách nào đó và tỷ lệ phần trăm ước tính. Rốt cuộc, phải có một lượng hướng dẫn hữu hạn được thực thi để hoàn thành một thao tác. Đây có phải chỉ đơn giản là mã hóa kém, hoặc có một số lý do cơ bản đại diện cho tiến trình là khó khăn?

Để thêm vào các câu trả lời chung chung hơn cho đến nay tôi có thể đưa ra một vài ví dụ từ lĩnh vực của mình nơi các thanh tiến trình không hoạt động và tại sao;

Các chương trình thiết kế hỗ trợ máy tính - các chương trình thực hiện phân tích nhiệt hoặc cơ học chất lỏng có thể nói chung là khủng khiếp với các thanh tiến trình. Họ nhảy về phía trước, lùi lại, thực hiện các bước không nhất quán và gần như không có ích gì khi xem chúng. Điều này là do tính chất lặp của các loại mô phỏng này và nhu cầu tìm sự hội tụ. Điều này được xem tốt nhất không phải bởi một thanh tiến trình mà bởi một âm mưu hội tụ v lặp.

Mô phỏng phức tạp - Tôi đã viết một chương trình mô phỏng một môi trường phức tạp với nhiều yếu tố liên quan chéo. Đó là cho một dòng thời gian cố định vì vậy bạn muốn thanh tiến trình này có thể là thời gian đúng không? Trong trường hợp của tôi, việc mô phỏng quá dài với mỗi bước thời gian mới, do đó có nghĩa là thanh tiến trình ngày càng chậm hơn - không lớn. Tôi đã tìm thấy một số liệu khác về thời gian mô phỏng trung bình mất bao lâu dựa trên số lượng vật phẩm trong mô phỏng gần với độ chính xác hơn - nhưng không lý tưởng vì đôi khi thanh quá trình không bao giờ được lấp đầy (mô phỏng dừng trước đó) hoặc đạt 100% đến sớm (chạy mô phỏng lâu hơn dự kiến).

Trong cả hai trường hợp, một thanh hoàn thành tiến trình thuần túy sẽ không thể tính được mức tối đa cho trước (trường hợp 1) hoặc không tuyến tính và do đó không sử dụng nhiều (trường hợp 2)

Cả hai. Đôi khi thật khó để ước tính thời gian thực hiện một thao tác, bởi vì bạn không biết trước bao nhiêu công việc cần phải hoàn thành. Đôi khi ước tính đơn giản và không chính xác của nó.

Ví dụ: Tôi đang tải xuống bốn tệp cùng một lúc. Ai đó biết mỗi tệp lớn bao nhiêu, đã tải xuống bao nhiêu và tải xuống bao nhiêu megabyte mỗi giây cho mỗi tệp. Có vẻ dễ dàng để dự đoán sẽ mất bao lâu. Tuy nhiên, tôi biết rằng sau khi một tệp được tải xuống, những tệp khác sẽ tải xuống nhanh hơn. Thậm chí nhiều hơn sau khi 3 tập tin được tải xuống; cái cuối cùng sẽ tải xuống nhanh hơn bốn lần. Chưa bao giờ thấy bất kỳ thanh tiến trình có tính đến điều này.

Ví dụ: Bạn đang sao chép một thư mục lớn. Thanh tiến trình giả định rằng bạn sao chép X megabyte mỗi giây, biết có bao nhiêu megabyte và tốc độ trung bình của bạn cho đến nay. Vấn đề là, "megabyte mỗi giây" rất không chính xác - trong thực tế, phải mất x mili giây trên mỗi tệp, cộng với y mili giây trên mỗi megabyte. Vì vậy, rất nhiều tệp nhỏ mất nhiều thời gian hơn so với thanh tiến trình dự đoán.

Vấn đề là các nhà phát triển phần mềm có thể quan tâm, nhưng người quản lý của họ không miễn là máy tính của bạn không gặp sự cố.

Tôi nghĩ rằng câu trả lời bao quát là nó thường quá phức tạp (hoặc không thể) để tính lượng thời gian cần thiết.

Đôi khi, đó chỉ là vấn đề cần thêm thời gian tính toán để ước tính tốt hơn số lượng công việc cần thiết (ví dụ: phân tích tốt hơn các tệp sẽ được sao chép hoặc áp dụng phép tính phức tạp hơn để ước tính tốt hơn số bước cần thiết để hoàn thành một mô phỏng).

Những lần khác, nó khá là không xác định. Khi hệ thống của bạn đang cài đặt một chương trình mới, nó thường có nhiều phụ thuộc để kiểm tra được cài đặt. Và nói chung, nó không có ý tưởng về việc mỗi người sẽ mất bao lâu và những phụ thuộc mà những người này có thể cần đến. Bạn có thể đã cài đặt tất cả các phụ thuộc và có thể mất 30 giây hoặc bạn có thể thiếu hàng tá và phải mất hàng giờ. Khó có thể đưa ra một sân bóng công bằng về điều đó, đặc biệt là khi mỗi tình huống sẽ là duy nhất.

Ngoài ra, các cống khác trên hệ thống có thể thay đổi theo thời gian (do những gì người dùng thực hiện ... hoặc quá trình nền / lịch trình).

Đôi khi ước tính có thể được cải thiện nếu lập trình viên sẽ đưa thêm một chút công việc vào chúng. Nhưng sau đó, một thực tế khác có lẽ đây không phải là mối quan tâm hàng đầu của các nhà phát triển, so với việc tiếp tục thực hiện các nhiệm vụ sản xuất thực tế mà ứng dụng có thể thực hiện.

Cuối cùng, ngay bây giờ, tôi tin rằng nó thường chỉ là một ước tính tuyến tính - xem xét có bao nhiêu nhiệm vụ cơ bản cần thiết đã hoàn thành chương trình. Vì vậy, nó thực sự có xu hướng là một ước tính rất sơ bộ, và bạn thường nên xem xét nó như vậy đi vào.

---

Một sự tương tự tốt có thể là khi bạn đang đọc một cuốn sách.
Và bạn quyết định bạn muốn có một ý tưởng về việc mất bao lâu để hoàn thành cuốn sách ...
Bạn có thể kiểm tra số lượng trang và có được ước tính nhanh dựa trên tốc độ cho đến nay.
Nó có thể là một ước tính xấu nếu bạn mới bắt đầu đọc, bởi vì tốc độ của bạn có thể chưa phải là điển hình. Nhưng thường thì đó là một phỏng đoán sơ bộ.
Hoặc bạn cũng có thể đọc lướt qua cuốn sách, hiểu sơ bộ về số lượng hình ảnh và khoảng cách văn bản. Và sau đó có một ý tưởng tốt hơn về những gì bạn phải đối mặt.
Nhưng nó vẫn có thể là một ước tính kém nếu, ví dụ, khả năng đọc văn bản giảm, có lẽ chuyển từ văn xuôi đơn giản sang phức tạp. Hoặc ước tính có thể kết thúc sai vì bạn không lường trước được một nhiệm vụ khác sẽ chuyển hướng sự chú ý của bạn.
Bạn có thể có được một ước tính tuyệt vời bằng cách áp dụng một lượng lớn thời gian để phân tích cẩn thận những gì còn lại trong trang sách theo từng trang, và cũng có thể cải thiện nó bằng cách kiểm tra lịch của bạn và giữ một danh sách các bước đọc dài hạn cho các cuốn sách khác nhau.
Nhưng cuối cùng, thời gian cần thiết để làm như vậy có đáng để trì hoãn việc chỉ đọc cuốn sách không?

---

Tất cả chúng ta đều thích các chỉ số tốt hơn. Nhưng cũng như vậy, có lẽ chúng ta sẽ phải đưa ra các ước tính sơ bộ, ít nhất là cho đến khi toàn bộ máy tính bắt đầu nhận được các thuật toán tiêu chuẩn hóa được cải thiện và có khả năng cân nhắc và dự đoán các yếu tố động "thông minh" (như cách của bạn)!

Và thanh tiến trình trên đó có thể bị kẹt ở mức 5% ngay bây giờ. Chúng ta sẽ phải xem điều đó diễn ra như thế nào 8-)

Tôi muốn thêm vào câu trả lời của @ gnasher729 rằng đây là một hậu quả tiềm ẩn khác của tính không ổn định của vấn đề tạm dừng.

Đặt sự khó lường vốn có của các tính toán tương tác, ngay cả những tính toán có thể bị cô lập có thể có thời gian thực hiện (và "nhịp điệu"), mà phương pháp dự đoán không thể tiếp cận được bằng phương pháp chung.

Đáng buồn thay, một thanh tiến trình thường là một phép ẩn dụ vô dụng. Điều gì sẽ là sự thay thế, bạn có thể yêu cầu. Nếu người dùng nhận thức được những gì đang diễn ra "dưới mui xe", việc thêm một số thông tin ngữ nghĩa vào giao diện có thể là một tùy chọn, chuyển sang thực thi giống như chế độ theo dõi. Nếu không, tạo ra một bầu không khí bình tĩnh làm giảm kỳ vọng.

Giáo dục người dùng hiểu những hạn chế của chúng tôi là một lựa chọn thứ ba - dài hạn.

Thanh tiến trình được rút ra dựa trên số lượng nhiệm vụ hoàn thành thay vì thời gian trôi qua / yêu cầu để hoàn thành.

Ví dụ: giả sử một thao tác X có bốn bước phụ khác nhau, ở cuối mỗi bước bạn tăng 25% thanh tiến trình. Nếu một bước mất nhiều thời gian hơn để thực hiện, bạn có thể sẽ thấy hành vi bạn đã mô tả - 1 đến 90% trong một lần và hàng giờ cho phần còn lại.

Logic đằng sau việc sử dụng số lượng nhiệm vụ như một đơn vị thay vì thời gian là cái sau không thể đoán trước được. Ngay cả trong trường hợp tải xuống một tệp, kết nối có thể bị giảm, do đó thời gian không thể được sử dụng như một đơn vị. Bạn thà sử dụng lượng byte được tải xuống chứ không phải thời gian cần thiết như một đơn vị tiến trình.