Trong thời đại của điện toán hiện đại, trong 'ứng dụng kinh doanh điển hình' - tại sao hiệu suất lại quan trọng? [đóng cửa]

Điều này có vẻ như một câu hỏi kỳ lạ đối với một số bạn.

Tôi là một lập trình viên Java có sở thích. Tôi đã phát triển một số trò chơi, một chương trình AI tạo ra âm nhạc, một chương trình khác để vẽ tranh và những thứ tương tự. Điều này là để nói với bạn rằng tôi có kinh nghiệm lập trình, nhưng không phát triển chuyên nghiệp các ứng dụng kinh doanh.

Tôi thấy rất nhiều cuộc nói chuyện trên trang web này về hiệu suất. Mọi người thường tranh luận điều gì sẽ là thuật toán hiệu quả nhất trong C # để thực hiện một tác vụ hoặc tại sao Python chậm và Java nhanh hơn, v.v.

Điều tôi đang cố gắng hiểu là: tại sao điều này lại quan trọng?

Có những lĩnh vực điện toán cụ thể mà tôi thấy tại sao hiệu năng lại quan trọng: trò chơi, trong đó hàng chục ngàn phép tính đang diễn ra mỗi giây trong một vòng cập nhật liên tục hoặc các hệ thống cấp thấp mà các chương trình khác dựa vào, như HĐH và VM, v.v.

Nhưng đối với các ứng dụng kinh doanh cấp cao thông thường, điển hình, tại sao hiệu suất lại quan trọng?

Tôi có thể hiểu tại sao nó từng là vấn đề, hàng thập kỷ trước. Máy tính chậm hơn nhiều và có ít bộ nhớ hơn, vì vậy bạn phải suy nghĩ cẩn thận về những điều này.

Nhưng ngày nay, chúng ta có rất nhiều bộ nhớ dự phòng và máy tính rất nhanh: có thực sự quan trọng nếu một thuật toán Java cụ thể là O (n ^ 2) không? Nó sẽ thực sự tạo ra sự khác biệt cho người dùng cuối của ứng dụng kinh doanh điển hình này?

Khi bạn nhấn nút GUI trong một ứng dụng kinh doanh thông thường và đằng sau hậu trường, nó sẽ gọi thuật toán O (n ^ 2), trong những ngày của máy tính hiện đại - bạn có thực sự cảm thấy không hiệu quả?

Câu hỏi của tôi được chia làm hai:

1. Trong thực tế, ngày nay hiệu suất có quan trọng trong một chương trình kinh doanh bình thường điển hình?
2. Nếu có, xin vui lòng cho tôi ví dụ thực tế về các địa điểm trong một ứng dụng như vậy, trong đó hiệu suất và tối ưu hóa là quan trọng.

Bạn nói đúng, hiệu suất trong các ứng dụng kinh doanh không thực sự là một chủ đề quan trọng theo cách nó được thảo luận bởi hầu hết các lập trình viên . Thông thường, các cuộc thảo luận liên quan đến hiệu suất mà tôi nghe được từ các lập trình viên có một số vấn đề:

• Họ chủ yếu là tối ưu hóa sớm . Thông thường, ai đó muốn "cách nhanh nhất" để thực hiện một thao tác mà không có lý do rõ ràng và cuối cùng sẽ thực hiện thay đổi mã được thực hiện bởi hầu hết các trình biên dịch (chẳng hạn như thay thế phép chia bằng cách nhân hoặc đặt nội tuyến) hoặc dành nhiều ngày để thay đổi Điều này sẽ giúp đạt được một vài micro giây khi chạy.

• Họ thường đầu cơ . Tôi rất vui khi thấy rằng trên Stack Overflow và Lập trình viên. E , hồ sơ được nhắc đến thường xuyên khi câu hỏi liên quan đến hiệu suất, nhưng tôi cũng thất vọng khi thấy hai lập trình viên không biết hồ sơ nào đang thảo luận về hiệu suất- những thay đổi liên quan họ nên làm trong mã của họ. Họ tin rằng những thay đổi sẽ khiến mọi thứ nhanh hơn, nhưng thực tế mọi lúc, nó sẽ không có tác dụng rõ ràng hoặc làm chậm mọi thứ, trong khi một trình hồ sơ sẽ chỉ chúng đến một phần khác của mã có thể dễ dàng tối ưu hóa và gây lãng phí 80% của thời gian

• Họ chỉ tập trung vào các khía cạnh kỹ thuật. Hiệu suất của các ứng dụng hướng đến người dùng là về cảm giác: nó có cảm giác nhanh và phản hồi nhanh không, hay nó cảm thấy chậm chạp và cồng kềnh? Trong bối cảnh này, các vấn đề về hiệu suất thường được các nhà thiết kế trải nghiệm người dùng giải quyết tốt hơn nhiều: một chuyển đổi hoạt hình đơn giản thường có thể là sự khác biệt giữa một ứng dụng cảm thấy chậm khủng khiếp và ứng dụng cảm thấy phản hồi nhanh, trong khi cả hai đều tiêu tốn 600 ms. làm các hoạt động.

• Chúng dựa trên các yếu tố chủ quan ngay cả khi chúng có liên quan đến các ràng buộc kỹ thuật. Nếu đó không phải là câu hỏi về cảm giác nhanh và phản hồi, thì cần phải có một yêu cầu phi chức năng trong đó chỉ định tốc độ thực hiện một thao tác trên dữ liệu cụ thể, chạy trên hệ thống cụ thể . Trong thực tế, nó xảy ra nhiều hơn như thế: người quản lý nói rằng anh ta tìm thấy một cái gì đó chậm, và sau đó, các nhà phát triển cần phải tìm ra điều đó có nghĩa là gì. Có phải nó chậm như trong "nó phải dưới 30 ms. Trong khi hiện tại, nó lãng phí mười giây" hoặc chậm như "chúng ta có thể giảm thời lượng từ mười xuống chín giây"?

Đầu tiên trong sự nghiệp là một lập trình viên, tôi đã làm việc trên một phần mềm cho một nhóm khách hàng của mình. Tôi đã bị thuyết phục rằng phần mềm này là điều tuyệt vời tiếp theo sẽ mang lại hạnh phúc cho thế giới, vì vậy tôi rõ ràng quan tâm đến hiệu suất.

Tôi đã nghe các thuật ngữ như "hồ sơ" hoặc "điểm chuẩn", nhưng tôi không biết ý nghĩa của chúng và không thể quan tâm ít hơn. Hơn nữa, tôi đã quá tập trung đọc cuốn sách về C, và đặc biệt là chương mà các kỹ thuật tối ưu hóa đã được thảo luận. Khi tôi phát hiện ra rằng máy tính thực hiện phép nhân nhanh hơn phép chia, tôi đã thay thế phép chia bằng phép nhân bất cứ nơi nào tôi có thể. Khi tôi phát hiện ra rằng việc gọi một phương thức có thể chậm, tôi đã kết hợp càng nhiều phương thức càng tốt, như thể 100 phương thức LỘC trước đó không phải là một vấn đề.

Đôi khi, tôi đã dành nhiều đêm để thực hiện các thay đổi, điều mà tôi đã bị thuyết phục, tạo ra sự khác biệt giữa một ứng dụng chậm mà không ai muốn và một ứng dụng nhanh mà mọi người đều muốn tải xuống và sử dụng. Việc hai khách hàng thực sự quan tâm đến ứng dụng này yêu cầu các tính năng thực tế không làm phiền tôi: "Ai sẽ muốn một tính năng, nếu ứng dụng chậm?" - tôi nghĩ.

Cuối cùng, hai khách hàng duy nhất ngừng sử dụng ứng dụng. Nó không nhanh đến mức đáng kinh ngạc bất chấp mọi nỗ lực của tôi, chủ yếu là vì khi bạn không biết chỉ mục là gì và ứng dụng của bạn cần nhiều cơ sở dữ liệu, có gì đó không đúng. Dù sao, khi tôi đang thực hiện một thay đổi khác liên quan đến hiệu suất, được cải thiện trong vài micrô giây, việc thực thi mã được sử dụng mỗi tháng một lần, khách hàng không thấy thay đổi. Những gì họ đã thấy là trải nghiệm người dùng rất tệ, tài liệu bị thiếu, các tính năng quan trọng mà họ yêu cầu trong nhiều tháng không có ở đây và số lượng lỗi cần giải quyết không ngừng tăng lên.

Kết quả: Tôi hy vọng ứng dụng này sẽ được sử dụng bởi hàng ngàn công ty trên khắp thế giới, nhưng hôm nay, bạn sẽ không tìm thấy bất kỳ thông tin nào về ứng dụng này trên internet. Hai khách hàng duy nhất đã từ bỏ nó, và dự án cũng bị bỏ rơi. Nó không bao giờ được bán trên thị trường, không bao giờ được quảng cáo công khai, và ngày nay, tôi thậm chí không chắc mình có thể biên dịch nó trên PC của mình (cũng không tìm thấy các nguồn gốc). Điều này sẽ không xảy ra nếu tôi tập trung nhiều hơn vào những thứ thực sự quan trọng.

Điều này đang được nói, hiệu suất nói chung là quan trọng :

• Trong các ứng dụng phi kinh doanh, nó có thể trở nên quan trọng. Có phần mềm nhúng , phần mềm chạy trên máy chủ (khi bạn có vài nghìn yêu cầu mỗi giây, điều đó không lớn, hiệu suất bắt đầu là vấn đề đáng lo ngại), phần mềm chạy trên điện thoại thông minh , trò chơi video , phần mềm dành cho chuyên gia (cố gắng xử lý một tệp 50 GB trong Photoshop trên một máy không quá nhanh để bị thuyết phục) và ngay cả các sản phẩm phần mềm thông thường được bán cho nhiều người (nếu Microsoft Word dành gấp đôi thời gian để thực hiện mọi thao tác, thời gian bị mất nhân với số của người dùng sẽ trở thành một vấn đề).

• Trong các ứng dụng kinh doanh, có nhiều trường hợp một ứng dụng mà cảm thấy và là chậm sẽ ghét bởi người sử dụng. Bạn không muốn điều đó, thực hiện các mối quan tâm của bạn.

Vâng. Vâng, nó làm. Tốc độ thời gian chạy không phải là mối quan tâm duy nhất bạn nên có, và nó không gây bức xúc như năm 1982, hay vẫn là trên các hệ thống nhúng công suất thấp, nhưng nó luôn là mối quan tâm và điều quan trọng là bạn hiểu tại sao lại như vậy

Đối với một, độ phức tạp tiệm cận mà bạn đề cập mô tả hành vi của một chương trình khi kích thước đầu vào của nó tăng lên . Một chương trình phi tuyến tính liên quan đến 10 mục có thể thoát khỏi công việc không cần thiết, nhưng nó sẽ cắn bạn khi một ngày bạn phải giải quyết 1000, vì nó sẽ không có vẻ chậm hơn, nhưng chậm hơn rất nhiều . Và bạn không biết (không có phân tích mở rộng và điểm chuẩn) liệu điểm đó sẽ ở mức 100 mặt hàng, ở 1000 mặt hàng hay không cho đến khi bạn đạt 100.000 mặt hàng. Có thể khó tin, nhưng việc chọn thuật toán tốt nhất là vấn đề thực tế dễ hơn rất nhiều so với việc ước tính điểm này cho mọi thói quen và chọn việc thực hiện của bạn tùy thuộc vào ước tính này.

Ngoài ra, xin vui lòng đọc lên những điều cơ bản kinh nghiệm người dùng. Có các ngưỡng được nghiên cứu kỹ lưỡng để xác định mức độ tương tác với chương trình được cảm nhận tùy thuộc vào thời gian phản hồi của nó (10ms, 100ms, vài giây, v.v.). Vượt qua một trong những ngưỡng này sẽ khiến người dùng từ bỏ ứng dụng của bạn và trừ khi bạn ở vị trí hài lòng khi viết phần mềm độc quyền mà mọi người phải sử dụng, người dùng từ chối chuyển trực tiếp sang giá trị doanh nghiệp tiêu cực vì dẫn đến mất khách hàng.

Đây chỉ là một vài lý do tại sao một lập trình viên chuyên nghiệp phải biết về độ phức tạp thuật toán và xử lý nó một cách có trách nhiệm. Ngày nay, không cần thiết phải đi ra khỏi chương trình của bạn và chương trình được tối ưu hóa đặc biệt, mã dễ đọc cho bất cứ thứ gì trừ khi nó trở thành vòng lặp bên trong quan trọng về thời gian, nhưng bạn không bao giờ nên gọi một lớp phức tạp cao hơn rõ ràng là cần thiết để làm công việc đó.

Có nó làm!

Vì bạn đã hỏi ví dụ, một số tình huống hàng ngày xuất hiện trong tâm trí:

1. Xử lý dữ liệu lớn : Nhiều ứng dụng kinh doanh được hỗ trợ bởi các cơ sở dữ liệu và trong nhiều trường hợp, các cơ sở dữ liệu này tràn ngập dữ liệu. Và vì không gian ổ đĩa rẻ, lượng dữ liệu được ghi và lưu trữ là điên rồ. Mới tuần trước, một khách hàng đã phàn nàn rằng ứng dụng của anh ta rất chậm, khi chỉ hiển thị một số con số trung bình (truy vấn trên một triệu hàng ...) - Ngoài ra, trong sử dụng hàng ngày, chúng tôi có chuyển đổi dữ liệu hàng loạt và tính toán với thời gian chạy trong một số giờ Năm ngoái, việc tối ưu hóa thuật toán đã khiến thời gian xử lý của một đợt giảm từ 8 xuống còn 4 giờ, bây giờ nó không còn va chạm với ca làm việc nữa!

2. Khả năng đáp ứng : Đã có những nghiên cứu về khả năng sử dụng (nếu có thời gian tôi sẽ thêm liên kết đến các câu hỏi có liên quan trên ux.se ...) rằng sự hài lòng của người dùng liên quan nhiều đến khả năng phản hồi. Sự khác biệt về thời gian đáp ứng 200ms so với 400ms có thể dễ dàng khiến bạn mất một tỷ lệ lớn khách hàng rời bỏ bạn cho đối thủ cạnh tranh.

3. Hệ thống nhúng : Máy tính không trở nên nhanh hơn, chúng ngày càng chậm hơn và nhỏ hơn ^ _ ^ Phát triển di động có tác động rất lớn đến phát triển ứng dụng. Chắc chắn chúng ta có thể xoay quanh bộ nhớ và chu kỳ CPU như Jelly Beans trên các máy tính để bàn hiện đại, nhưng bây giờ ông chủ của bạn yêu cầu bạn thực hiện thuật toán phân tích giấc ngủ trên đồng hồ freakin hoặc trên thẻ SIM ...

Trong thực tế, ngày nay hiệu suất có quan trọng trong một chương trình kinh doanh bình thường điển hình?

Tôi không biết chương trình kinh doanh thông thường là gì. Những gì tôi biết, là người dùng luôn kết thúc bằng cách cung cấp cho các chương trình của chúng tôi nhiều dữ liệu hơn chúng tôi dự định (thường sau khi hỏi họ sẽ lớn như thế nào và thêm một mức bảo mật) và trong trường hợp đó, họ mong đợi sự gia tăng tuyến tính thời gian chạy, chấp nhận một hành vi log n và phàn nàn rằng ứng dụng đóng băng khi có bất cứ điều gì khác xảy ra. Và họ có xu hướng xem xét kích thước của kết quả nhiều hơn kích thước của đầu vào ngoại trừ trong trường hợp POV của họ rõ ràng rằng tất cả dữ liệu đầu vào phải được xử lý.

Vì vậy, có, hiệu suất, ít nhất là ở mức độ phức tạp, vấn đề. Tối ưu hóa vi mô trong một lớp phức tạp không thực sự quan trọng, ngoại trừ nếu bạn kém hơn so với đối thủ (về điểm chuẩn ở một số thị trường hoặc bởi nhận thức thô - thay đổi lớp trong tiến trình "tức thời", "không tức thời nhưng người dùng không 't chuyển sang thứ khác "," đủ chậm để người dùng chuyển sang thứ khác có nguy cơ làm gián đoạn dòng hành động "," đủ chậm để người dùng khởi chạy tác vụ và sau đó kiểm tra theo thời gian "," đủ chậm người dùng có kế hoạch khởi động nhiệm vụ vào bữa trưa, qua đêm, vào cuối tuần ").

Trong các ứng dụng kinh doanh hiện đại, các vấn đề về hiệu năng không phải là thiếu CPU hay bộ nhớ. Nhưng chúng ở dạng độ trễ mạng, hiệu năng I / O và trừu tượng ẩn tất cả những thứ đó. Tất cả phụ thuộc vào thiết kế tốt như thế nào và các nhà phát triển có kinh nghiệm như thế nào. Ngay cả ứng dụng CRUD đơn giản cũng có thể thu thập dữ liệu tạm dừng nếu nó đang kéo từ DB một hàng tại một thời điểm thay vì chạy truy vấn (còn được gọi là vấn đề N + 1).

Vấn đề là có thiết kế tốt và các nhà phát triển có kinh nghiệm là tốn kém. Và nó thường rẻ hơn nhiều khi khiến người dùng khó chịu hơn là đầu tư vào tối ưu hóa hiệu suất thực tế. Có một số trường hợp, trong đó khách hàng sẽ yêu cầu hiệu suất cao (ví dụ: trình duyệt web), nhưng những trường hợp này hiếm khi áp dụng cho các ứng dụng kinh doanh phổ biến.

Hãy nhớ rằng đối với các ứng dụng dựa trên máy chủ, bạn có thể có hàng trăm, hàng nghìn hoặc thậm chí hàng triệu người dùng đang cố gắng thực hiện cùng một lúc. Một khoản tiết kiệm nhỏ về hiệu quả trong tình huống như vậy có thể có tác động lớn đến lượng phần cứng cần thiết cho các yêu cầu dịch vụ.

Nó chắc chắn là vấn đề rất nhiều.

Vấn đề chính thậm chí không gây khó chịu cho người dùng, chẳng hạn như gặp phải sự chậm trễ không cần thiết khi các thành phần GUI bị rút hai lần hoặc ba lần (điều này không quan trọng trên đồ họa tích hợp!) Hoặc đơn giản là vì chương trình mất quá nhiều thời gian để làm ... không (chủ yếu là những thứ không thú vị). Mặc dù tất nhiên, đó cũng là một vấn đề.

Có ba quan niệm sai lầm quan trọng:

1. Hầu hết các máy tính kinh doanh điển hình không "mạnh hơn nhiều" . Máy tính doanh nghiệp thông thường không phải là i7 8 nhân với card đồ họa kick-ass và 16GB RAM. Đó là một máy tính xách tay với bộ xử lý di động trung cấp, đồ họa tích hợp, bộ nhớ chính 2 GB (4GB nếu bạn may mắn), đĩa 5400RPM và phiên bản Windows dành cho doanh nghiệp với nhiều phần mềm chống vi-rút và thi hành chính sách thời gian thực chạy trong lý lịch. Hoặc, đối với hầu hết các chuyên gia tư vấn, "máy tính" chỉ đơn giản là iPhone ...
2. Hầu hết "người dùng doanh nghiệp thông thường" không phải là kỹ thuật viên, họ không hiểu ý nghĩa của việc tạo bảng tính với 10-12 tab tham chiếu chéo, 150 cột và 30.000 hàng (những con số này không thực tế như bạn nghĩ!) Và chúng cũng không muốn biết. Họ sẽ chỉ làm điều đó.
3. Mất thứ hai không phải là một giả định sai lầm rõ ràng.

Vợ tôi làm việc ở cấp cao của một "môi trường kinh doanh điển hình" như vậy. Chiếc máy tính mà cô ấy đang sử dụng có giá khoảng 3,5 giờ thời gian làm việc của cô ấy có giá trị. Bắt đầu Microsoft Outlook mất - vào một ngày tốt - khoảng 3 phút cho đến khi nó sẵn sàng (6-8 phút vào cuối quý khi các máy chủ đang tải nặng). Một số bảng tính 30 nghìn hàng được đề cập mất 2-3 giây để cập nhật giá trị trong đó máy tính bị "đóng băng" (chưa kể mất bao lâu để Excel khởi động và mở chúng ở vị trí đầu tiên!). Thậm chí còn tệ hơn khi chia sẻ máy tính để bàn. Đừng để tôi tiếp tục với SAP.
Nó chắc chắn có vấn đề cho dù một trăm ngàn người mỗi người mất 20-25 phút mỗi ngày làm việc không chờ đợi điều gì. Đó là hàng triệu người mấtmà bạn có thể, thay vì mất chúng, trả cổ tức (hoặc trả lương cao hơn).
Chắc chắn, hầu hết các nhân viên đều ở mức thấp hơn trong mức lương, nhưng ngay cả ở thời điểm thấp hơn là tiền .

Tôi có thể hiểu tại sao nó từng là vấn đề, hàng thập kỷ trước. Máy tính chậm hơn nhiều và có ít bộ nhớ hơn, vì vậy bạn phải suy nghĩ cẩn thận về những điều này.

Bạn dường như đánh giá thấp N ^ 2 phát triển nhanh như thế nào. Hãy nói rằng chúng tôi có một máy tính và thuật toán N ^ 2 của chúng tôi mất 10 giây khi N = 10. Thời gian trôi qua chúng tôi có bộ xử lý mới nhanh hơn 6 lần so với bản gốc của chúng tôi vì vậy tính toán 10 giây của chúng tôi bây giờ ít hơn hai giây. N có thể lớn hơn bao nhiêu và vẫn vừa trong thời gian chạy 10 giây ban đầu đó? Bây giờ chúng tôi có thể xử lý 24 mặt hàng, nhiều hơn gấp đôi. Hệ thống của chúng ta sẽ nhanh hơn bao nhiêu để xử lý số lượng vật phẩm gấp 10 lần? Vâng, nó sẽ phải nhanh hơn 100 lần. Dữ liệu phát triển khá nhanh và nhiều hơn là xóa sạch tiến trình phần cứng máy tính cho các thuật toán N ^ 2.

Bạn sẽ không tin vào số lượng chương trình kinh doanh của bên thứ 3 mà chúng tôi sử dụng tại nơi làm việc và nhiều chương trình trong số đó chỉ chậm sử dụng so với tiêu chuẩn cá nhân của tôi. Nếu các chương trình là thứ tôi sử dụng ở nhà, tôi đã thay thế chúng bằng một chương trình thay thế từ lâu rồi.

Trong một số trường hợp, sự khác biệt sẽ ảnh hưởng trực tiếp đến chi phí, vì một số chương trình ảnh hưởng trực tiếp đến số lượng nhiệm vụ tôi có thể hoàn thành trong một ngày, do đó làm giảm năng suất và số lượng các mặt hàng có thể tính hóa đơn. Vì vậy, tôi sẽ nói rằng nó cũng khá quan trọng đối với các chương trình kinh doanh, ít nhất là đủ hiệu quả để không trở thành mục giới hạn cho thu nhập.

Một ví dụ là quản lý sự cố trong đó công việc được đo trong khoảng thời gian 15 phút (bàn dịch vụ). Nếu chương trình đủ chậm để đẩy một vé mất hơn 15 phút (bao gồm cả công việc thực tế), nó sẽ làm chậm quá trình khá nhiều. Một nguyên nhân có thể là truy cập cơ sở dữ liệu chậm chỉ đơn giản là "chờ một lúc" bất cứ khi nào người dùng thực hiện một hành động (điền chi tiết độ phân giải, cập nhật thông tin công việc hoặc tương tự). Tôi có thể tưởng tượng có những trường hợp chương trình chậm thậm chí có thể ảnh hưởng đến những điều quan trọng hơn, chẳng hạn như chi tiết bệnh nhân trong bệnh viện về các trường hợp ngộ độc khẩn cấp - có thể là dị ứng thuốc hoặc như vậy?

Nhiều câu trả lời khác bao gồm chủ đề khá kỹ lưỡng, vì vậy tôi nói với họ về lý do và lý do. Thay vào đó, tôi muốn đưa ra một ví dụ thực tế để cho thấy một lựa chọn thuật toán có thể có ý nghĩa thực sự như thế nào.

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-probols

Bài viết được liên kết mô tả một lỗi trong thuật toán để tính toán các bản cập nhật Windows XP. Trong phần lớn thời gian sử dụng Windows XP, thuật toán cập nhật hoạt động tốt. Thuật toán tính toán xem một bản vá đã được thay thế bởi một bản vá mới hơn hay chưa và do đó không cần cài đặt. Tuy nhiên, về cuối, danh sách các bản cập nhật thay thế đã tăng rất dài *.

Thuật toán cập nhật là theo cấp số nhân, trong đó mỗi bản cập nhật mới mất gấp đôi thời gian để tính toán như lần trước ( ). Khi danh sách lên đến 40 phạm vi cập nhật (* dài ), phải mất tới 15 phút, chạy hết công suất, để kiểm tra cập nhật. Điều này có hiệu quả khóa nhiều máy XP trong quá trình cập nhật. Tệ hơn nữa, khi một người đi cài đặt các bản cập nhật, thuật toán sẽ chạy lại , mất thêm 15 phút nữa. Vì nhiều máy đã được cài đặt Cập nhật tự động, điều này có thể khóa máy trong 15 phút mỗi lần khởi động và có khả năng trở lại ở một chu kỳ nhất định.O(n) = 2n

Microsoft đã sử dụng cả các bản hack ngắn hạn (xóa các mục khỏi danh sách cập nhật) và các bản sửa lỗi dài hạn để giải quyết vấn đề này. Điều này rất quan trọng vì các phiên bản Windows mới nhất cũng sử dụng cùng một thuật toán và một ngày nào đó có thể phải đối mặt với cùng một vấn đề.

Ở đây chúng ta có thể thấy rằng sự lựa chọn của một thuật toán có ý nghĩa thực sự. Thuật toán sai, trong khi tốt cho hầu hết tuổi thọ của sản phẩm, vẫn có thể có tác động tiêu cực xuống đường.

Tôi nghĩ rằng bạn đang diễn giải số lượng câu hỏi được hỏi về hiệu suất như một dấu hiệu cho thấy các yêu cầu về hiệu suất cho các ứng dụng kinh doanh là quan trọng thay vì nhận ra rằng việc cải thiện hiệu suất là khó khăn . Chỉ cần làm cho nó hoạt động có thể được thực hiện bằng các kỹ thuật vũ phu, thử nghiệm và lỗi hoặc sao chép và dán mã ví dụ.

Bất cứ ai cũng có thể gặp may mắn và tiếp tục thực hiện các thay đổi cho đến khi một cái gì đó chạy nhanh hơn, nhưng điều đó hiếm khi hoạt động. Do thiếu kinh nghiệm, các nhà phát triển sẽ thấy sự giúp đỡ bên ngoài. Trong một số môi trường, cải tiến hiệu suất là một vấn đề duy nhất, do đó, đặt câu hỏi cụ thể trên một trang web như StackOverflow có thể là lựa chọn duy nhất. Ngoài ra, nhiều chuyên gia tư vấn kiếm tiền bằng cách có thể bước vào và khắc phục các loại vấn đề này.

Nó phụ thuộc rất nhiều vào cách bạn định nghĩa "hiệu suất tốt". Các thuật toán của bạn phải luôn luôn sử dụng độ phức tạp tốt nhất có thể. Lạm dụng sơ hở để tăng tốc lồng trung bình của bạn. Bộ đệm và tải trước / tiền biên dịch bất cứ nơi nào có thể trong một chương trình tương tác.

Có một định nghĩa khác về "hiệu suất tốt": Tối ưu hóa các hằng số của lớp phức tạp của bạn. Đây là nơi C ++ có được danh hiệu của mình, nơi mọi người bắt đầu gọi Java chậm, trong đó thời gian chạy ít hơn 5% dường như là chén thánh. Sử dụng định nghĩa này là bạn đúng. Phần cứng máy tính trở nên phức tạp hơn theo thời gian, trong khi trình biên dịch ngày càng tốt hơn. Tại một số điểm, bạn không thể thực sự tối ưu hóa mã cấp thấp tốt hơn trình biên dịch - vì vậy hãy để nó và tập trung vào các thuật toán của bạn.

Tại thời điểm đó, sử dụng Java / Haskell / C ++ trở thành một quyết định thiết kế khác. Việc bẻ số có thể được thực hiện thông qua OpenCL trên GPU của bạn. Giao diện người dùng cần các thuật toán thời gian liên tục và chúng tốt. Đầu ra và tính mô-đun quan trọng hơn việc sắp xếp các lớp của bạn để sử dụng bộ đệm tốt hơn 20%. Đa luồng trở nên quan trọng, bởi vì mọi người không muốn có một ứng dụng nhanh, họ muốn một ứng dụng đáp ứng. Điều không quan trọng là ứng dụng của bạn liên tục chậm hơn 10% so với khả năng của nó. Thậm chí 50% là ổn (nhưng mọi người bắt đầu đặt câu hỏi sau đó). Tập trung vào tính chính xác, đáp ứng và mô-đun.

Tôi thích lập trình trong Haskell hoặc ít nhất là ở dạng chức năng (ngay cả trong C ++). Có thể viết các bài kiểm tra dễ dàng cho toàn bộ chương trình của bạn chỉ quan trọng hơn là nhanh hơn một chút trong các công việc hàng loạt.

Khá đơn giản: chi phí

Chủ nhân trước đây của tôi có một hệ thống quản lý học tập được lưu trữ trên các máy chủ vật lý dưới dạng mô hình SaaS. Heap của JVM được cấu hình thành 2 GB cho các máy cũ hơn và 3 GB cho các máy mới hơn và chúng tôi đã chạy một số phiên bản cho mỗi máy. Bạn sẽ nghĩ thế là đủ.

Trước khi tôi bắt đầu, đã có một nhóm hiệu suất chịu trách nhiệm làm cho hệ thống đáp ứng và quy mô. Họ thấy rằng có những mẩu dữ liệu nhất định mà chúng tôi đã truy vấn từ cơ sở dữ liệu liên tục. Có một bảng chúng tôi thậm chí đã tham gia vào hầu hết các truy vấn để lấy một cột. Dữ liệu đó hiếm khi thay đổi.

Vấn đề là, chúng tôi đã có 2 GB để làm việc. Vì vậy, giải pháp rõ ràng là bắt đầu lưu trữ tất cả các dữ liệu thường xuyên đọc. Sau đó chúng tôi gặp vấn đề về trí nhớ, bắt đầu ngay trước khi tôi lên tàu.

Có 2 trường phái suy nghĩ về điều này:

1. Bộ nhớ và phần cứng nói chung là giá rẻ những ngày này. Chỉ cần mua thêm RAM để bạn có thể lưu trữ nhiều bộ nhớ cache hơn.
2. Tại sao một hệ thống quản lý học tập cần hơn 3 GB RAM? Tất cả những gì nó tạo ra các truy vấn SQL, gửi chuyển hướng để khởi chạy các khóa học và đánh giá sự tiến bộ của sinh viên thông qua các khóa học.

Đối số thứ hai đã thắng và tôi đã dành hơn một năm để điều chỉnh việc sử dụng bộ nhớ của chúng tôi.

Chủ nhân hiện tại của tôi cũng tổ chức một hệ thống quản lý học tập, nhưng lưu trữ nó hơi khác một chút. Khả năng mở rộng kém đến mức một cài đặt (chia cho 4 máy chủ ảo cân bằng tải) chỉ có thể xử lý 80 khách hàng. Một số khách hàng lớn hơn của chúng tôi thậm chí có được bộ máy chủ của riêng họ. Hầu hết các vấn đề dẫn đến điều này là các vấn đề về hiệu năng, như các truy vấn SQL làm hỏng tất cả các chu kỳ CPU, rò rỉ bộ nhớ, mã dự phòng thực hiện cùng một việc nhiều lần. Chúng tôi thậm chí có một ứng dụng nội bộ được xây dựng với mục đích duy nhất là khởi động lại máy chủ khi chúng hoạt động kém. Có một nhân viên duy trì công cụ đó (cùng với các trách nhiệm khác).

Họ đăng ký vào trường phái đầu tiên mà tôi đã đề cập ở trên: ném nhiều phần cứng vào nó vì chi phí phần cứng rẻ hơn so với lương của nhà phát triển.

Điều này đã không làm việc như kinh tế như mong đợi. Giữa phần cứng, cấp phép phần mềm và nhân viên hỗ trợ để xử lý các máy chủ, chúng tôi đã chi hàng triệu đô la mỗi năm để tránh việc nhà phát triển dành thời gian lập hồ sơ mã.

Khi tôi tham gia, tôi đã chịu trách nhiệm sửa chữa các vấn đề sẵn có của chúng tôi. Vì hầu hết các vấn đề về tính khả dụng của chúng tôi là do hiệu suất kém, tôi đã điều chỉnh hiệu suất mã của chúng tôi và khả năng mở rộng được cải thiện đáng kể, với thời gian hoạt động tốt hơn nhiều. Chúng tôi đã sẵn sàng để bắt đầu tăng mật độ. Không cần phải nói, tiền lương của tôi không ở mức gần một triệu (tôi ước!), Vì vậy, chi tiền cho việc điều chỉnh hiệu suất của tôi sẽ giúp chúng tôi tiết kiệm hàng triệu đô la mỗi năm.

TL; DR

Nếu bạn thực hiện một phân tích chi phí / lợi ích kỹ lưỡng, bạn sẽ thấy rằng chỉ cần sửa mã là rẻ hơn. Một vấn đề hiệu suất được biết đến mà bạn bỏ qua biến thành nợ kỹ thuật .

Tôi hiểu câu hỏi của bạn như thế này: để đạt được hiệu suất đủ tốt (tức là người dùng hài lòng và phần phụ trợ của tôi không bị co rúm), tôi có cần hiểu lý thuyết về độ phức tạp thuật toán không?

Nó phụ thuộc vào những gì bạn có nghĩa là ứng dụng kinh doanh "điển hình". Trong nhiều trường hợp, đặc biệt là các hệ thống thông tin giống CRUD đơn giản, câu trả lời sẽ là không. Đối với những người này, bạn sẽ "đơn giản" (đôi khi thực sự khó khăn) cần có thể theo dõi các nút thắt biểu diễn: tôi có bỏ lỡ một chỉ mục trong cơ sở dữ liệu của mình không? Tôi có gửi quá nhiều dữ liệu qua mạng không? Tôi có đồng hồ nghìn đô trong giao diện angular.js của mình không? Đây là về việc xây dựng một kiến ​​trúc âm thanh, hiểu rõ công nghệ của bạn và tránh vô nghĩa. Bạn có thể đạt được điều đó nếu bạn là một người giỏi, không nhất thiết phải là một nhà khoa học máy tính. Một cách khác để nói rằng những người xây dựng trình tối ưu hóa truy vấn Oracle đã xử lý các công cụ phức tạp về thuật toán, bạn chỉ cần sử dụng đúng những gì họ cung cấp cho bạn.

Bây giờ có ngoại lệ. Nếu chúng ta đang nói về dữ liệu lớn hoặc học máy, bạn cần biết những gì bạn đang làm và không chỉ sử dụng các thuật toán mặc định có sẵn cho bạn. Ngay cả ở mặt trước, nếu bạn bắt đầu xây dựng trực quan hóa dữ liệu nâng cao, một số trong số chúng có thể ngụ ý chi phí phức tạp phi tuyến tính (ví dụ: biểu đồ bố trí lực lượng).

Ngày nay những ngoại lệ này ngày càng trở nên phổ biến và thị trường khá khô khan khi bạn tìm kiếm những người có thể xử lý chúng. Vì vậy: có, bạn có thể thành công mà không có nền tảng khoa học máy tính, nhưng bạn sẽ còn hơn thế nữa với một số người.

Những người phản hồi khác đã đề cập đến hầu hết các điểm cơ bản, nhưng đối với các tác vụ có thể song song, phần mềm không hiệu quả dẫn đến tăng chi phí phần cứng dưới dạng nhiều máy chủ hơn, sử dụng nhiều năng lượng hơn và cần nhiều không gian và bảo trì hơn.