Có nên tránh STL trong các ứng dụng lớn?

Điều này có vẻ như là một câu hỏi kỳ lạ, nhưng trong bộ phận của tôi, chúng tôi đang gặp rắc rối với tình huống sau:

Chúng tôi đang làm việc ở đây trên một ứng dụng máy chủ, ngày càng lớn hơn, thậm chí tại thời điểm chúng tôi đang xem xét chia nó thành các phần khác nhau (tệp DLL), tải động khi cần và dỡ tải sau đó, để có thể xử lý các vấn đề hiệu suất.

Nhưng: các hàm chúng ta đang sử dụng, đang truyền tham số đầu vào và đầu ra dưới dạng các đối tượng STL và như được đề cập trong câu trả lời Stack Overflow , đây là một ý tưởng rất tồi. (Bài đăng có chứa một số giải pháp và hack, nhưng tất cả trông không chắc chắn lắm.)

Rõ ràng chúng ta có thể thay thế các tham số đầu vào / đầu ra bằng các loại C ++ tiêu chuẩn và tạo các đối tượng STL từ các đối tượng một lần bên trong các hàm, nhưng điều này có thể làm giảm hiệu suất.

Bạn có thể kết luận rằng, trong trường hợp bạn đang xem xét xây dựng một ứng dụng, có thể phát triển đến mức mà một PC duy nhất không thể xử lý được nữa, bạn không được sử dụng STL như một công nghệ?

Thông tin thêm về câu hỏi này:
Dường như có một số hiểu lầm về câu hỏi: vấn đề là như sau:
Ứng dụng của tôi đang sử dụng một lượng lớn hiệu năng (CPU, bộ nhớ) để hoàn thành công việc của mình và tôi muốn chia nhỏ công việc này vào các phần khác nhau (vì chương trình đã được chia thành nhiều hàm), không khó để tạo một số DLL ra khỏi ứng dụng của tôi và đưa một số hàm vào bảng xuất của các DLL đó. Điều này sẽ dẫn đến tình huống sau:

+-----------+-----------+----
| Machine1  | Machine2  | ...
| App_Inst1 | App_Inst2 | ...
|           |           |    
| DLL1.1    | DLL2.1    | ...
| DLL1.2    | DLL2.2    | ...
| DLL1.x    | DLL2.x    | ...
+-----------+-----------+----

App_Inst1 là phiên bản của ứng dụng, được cài đặt trên Machine1, trong khi App_Inst2 là phiên bản của cùng một ứng dụng, được cài đặt trên Machine2.
DLL1.x là một DLL, được cài đặt trên Machine1, trong khi DLL2.x là một DLL, được cài đặt trên Machine2.
DLLx.1 bao gồm chức năng xuất1.
DLLx.2 bao gồm chức năng xuất2.

Bây giờ trên Machine1 tôi muốn thực thi hàm1 và function2. Tôi biết rằng điều này sẽ quá tải Machine1, vì vậy tôi muốn gửi tin nhắn đến App_Inst2, yêu cầu ứng dụng đó thực hiện chức năng2.

Các tham số đầu vào / đầu ra của function1 và function2 là các đối tượng STL (Thư viện loại tiêu chuẩn C ++) và thường thì tôi có thể mong đợi khách hàng thực hiện cập nhật App_Inst1, App_Inst2, DLLx.y (nhưng không phải tất cả chúng, khách hàng có thể nâng cấp Machine1 nhưng không phải Machine2, hoặc chỉ nâng cấp các ứng dụng chứ không phải DLL hoặc ngược lại, ...). Rõ ràng nếu giao diện (tham số đầu vào / đầu ra) thay đổi, thì khách hàng buộc phải thực hiện nâng cấp hoàn chỉnh.

Tuy nhiên, như được đề cập trong URL StackOverflow được đề cập, việc biên dịch lại đơn giản App_Inst1 hoặc một trong các DLL có thể khiến toàn bộ hệ thống bị phá vỡ, do đó, tiêu đề ban đầu của bài đăng này, không khuyến khích sử dụng STL (Mẫu chuẩn C ++ Thư viện) cho các ứng dụng lớn.

Tôi hy vọng rằng tôi đã xóa một số câu hỏi / nghi ngờ.

Đây là một vấn đề XY cổ điển lạnh như đá.

Vấn đề thực sự của bạn là vấn đề hiệu suất. Tuy nhiên, câu hỏi của bạn cho thấy rõ rằng bạn đã không thực hiện hồ sơ hoặc đánh giá khác về vấn đề hiệu suất thực sự đến từ đâu. Thay vào đó, bạn hy vọng rằng việc chia mã của bạn thành DLL sẽ giải quyết vấn đề một cách kỳ diệu (điều này sẽ không xảy ra đối với hồ sơ), và bây giờ bạn lo lắng về một khía cạnh của giải pháp không phải đó.

Thay vào đó, bạn cần giải quyết vấn đề thực sự. Nếu bạn có nhiều tệp thực thi, hãy kiểm tra xem cái nào gây chậm. Trong khi bạn đang ở đó, hãy chắc chắn rằng chương trình của bạn thực sự chiếm hết thời gian xử lý và không phải là trình điều khiển Ethernet được cấu hình kém hoặc đại loại như thế. Và sau đó, bắt đầu cấu hình các tác vụ khác nhau trong mã của bạn. Bộ đếm thời gian chính xác cao là bạn của bạn ở đây. Giải pháp cổ điển là theo dõi thời gian xử lý trường hợp trung bình và trường hợp xấu nhất cho một đoạn mã.

Khi bạn có dữ liệu, bạn có thể tìm ra cách giải quyết vấn đề và sau đó bạn có thể tìm ra nơi để tối ưu hóa.

Nếu bạn phải phân chia một phần mềm giữa nhiều máy vật lý, bạn phải có một số dạng tuần tự hóa khi truyền dữ liệu giữa các máy vì chỉ trong một số trường hợp, bạn thực sự có thể gửi cùng một nhị phân chính xác giữa các máy. Hầu hết các phương thức tuần tự hóa không có vấn đề gì khi xử lý các loại STL vì vậy trường hợp đó không phải là điều khiến tôi lo lắng.

Nếu bạn phải chia một ứng dụng thành Thư viện chia sẻ (DLL) (trước khi thực hiện điều đó vì lý do hiệu năng, bạn thực sự cần đảm bảo rằng nó thực sự sẽ giải quyết vấn đề hiệu năng của bạn) vượt qua các đối tượng STL có thể là một vấn đề nhưng không phải như vậy. Như liên kết bạn đã cung cấp đã mô tả, việc truyền các đối tượng STL hoạt động nếu bạn sử dụng cùng một trình biên dịch và cùng các cài đặt trình biên dịch. Nếu người dùng cung cấp DLL, bạn có thể không dễ dàng tin tưởng vào điều này. Tuy nhiên, nếu bạn cung cấp tất cả các DLL và biên dịch mọi thứ cùng nhau thì bạn có thể tin tưởng vào nó và sử dụng các đối tượng STL qua các ranh giới DLL trở nên rất có thể. Bạn vẫn phải coi chừng các cài đặt trình biên dịch để không nhận được nhiều đống khác nhau nếu bạn vượt qua quyền sở hữu đối tượng, mặc dù đó không phải là vấn đề cụ thể của STL.

Chúng tôi đang làm việc ở đây trên một ứng dụng máy chủ, ngày càng lớn hơn, thậm chí tại thời điểm chúng tôi đang xem xét chia nó thành các phần khác nhau (DLL), tải động khi cần và dỡ tải sau đó, để có thể xử lý vấn đề hiệu năng

RAM là rẻ và do đó mã không hoạt động là giá rẻ. Tải và dỡ mã (đặc biệt là dỡ tải) là một quá trình mong manh và không có khả năng ảnh hưởng đáng kể đến hiệu suất chương trình của bạn trên phần cứng máy tính để bàn / máy chủ hiện đại.

Bộ nhớ cache đắt hơn nhưng điều đó chỉ ảnh hưởng đến mã đang hoạt động gần đây, chứ không phải mã đang sử dụng trong bộ nhớ.

Trong các chương trình chung vượt trội so với máy tính của họ vì kích thước dữ liệu hoặc thời gian CPU, không phải kích thước mã. Nếu kích thước mã của bạn ngày càng lớn đến mức gây ra vấn đề lớn thì có lẽ bạn muốn xem tại sao điều đó lại xảy ra ở nơi đầu tiên.

Nhưng: các hàm chúng ta đang sử dụng, đang chuyển tham số đầu vào và đầu ra dưới dạng các đối tượng STL và như được đề cập trong URL StackOverflow này, đây là một ý tưởng rất tồi.

Sẽ ổn thôi miễn là các dll và thực thi đều được xây dựng với cùng một trình biên dịch và được liên kết động với cùng một thư viện thời gian chạy C ++. Theo sau, nếu ứng dụng và các dll liên quan được xây dựng và triển khai thành một đơn vị thì đó không phải là vấn đề.

Nơi nó có thể trở thành vấn đề là khi các thư viện được xây dựng bởi những người khác nhau hoặc có thể được cập nhật một cách riêng biệt.

Bạn có thể kết luận rằng, trong trường hợp bạn đang xem xét xây dựng một ứng dụng, có thể phát triển đến mức một PC duy nhất không thể xử lý được nữa, bạn không được sử dụng STL như một công nghệ?

Không hẳn vậy.

Khi bạn bắt đầu truyền bá một ứng dụng trên nhiều máy, bạn có toàn bộ cân nhắc về cách bạn truyền dữ liệu giữa các máy đó. Các chi tiết về việc loại STL hoặc các loại cơ bản hơn được sử dụng có khả năng bị mất trong tiếng ồn.

Không, tôi không nghĩ rằng kết luận sau. Ngay cả khi chương trình của bạn được phân phối trên nhiều máy, không có lý do gì mà việc sử dụng STL trong nội bộ buộc bạn phải sử dụng nó trong giao tiếp giữa các mô-đun / quy trình.

Trên thực tế, tôi cho rằng bạn nên tách biệt thiết kế giao diện bên ngoài khỏi triển khai bên trong ngay từ đầu, vì trước đây sẽ cứng hơn / khó thay đổi so với những gì được sử dụng trong nội bộ

Bạn đang thiếu điểm của câu hỏi đó.

Về cơ bản có hai loại DLL. Của riêng bạn, và của người khác. "Vấn đề STL" là bạn và họ có thể không sử dụng cùng một trình biên dịch. Rõ ràng, đó không phải là vấn đề đối với DLL của riêng bạn.

Nếu bạn xây dựng các DLL từ cùng một cây nguồn cùng một lúc với cùng một trình biên dịch và các tùy chọn xây dựng, thì nó sẽ hoạt động tốt.

Tuy nhiên, cách "chia sẻ hương vị Windows" để chia một ứng dụng thành nhiều phần, một số trong đó có thể sử dụng lại là các thành phần COM . Chúng có thể nhỏ (điều khiển riêng hoặc codec) hoặc lớn (IE có sẵn dưới dạng điều khiển COM, trong mshtml.dll).

tải động khi cần và dỡ tải sau đó

Đối với một ứng dụng máy chủ, điều này có thể sẽ có hiệu quả khủng khiếp ; nó chỉ thực sự khả thi khi bạn có một ứng dụng di chuyển qua nhiều giai đoạn trong một khoảng thời gian dài để bạn biết khi nào một thứ gì đó sẽ không cần thiết nữa. Nó làm tôi nhớ các trò chơi DOS sử dụng cơ chế lớp phủ.

Ngoài ra, nếu hệ thống bộ nhớ ảo của bạn hoạt động tốt, nó sẽ xử lý việc này cho bạn bằng cách phân trang các trang mã không sử dụng.

có thể phát triển lớn đến mức một PC duy nhất không thể xử lý được nữa

Mua một PC lớn hơn.

Đừng quên rằng với việc tối ưu hóa đúng, một chiếc máy tính xách tay có thể vượt trội hơn một cụm hadoop.

Nếu bạn thực sự cần nhiều hệ thống, bạn phải suy nghĩ rất kỹ về ranh giới giữa chúng, vì đó là chi phí nối tiếp. Đây là nơi bạn nên bắt đầu xem xét các khung như MPI.

Chúng tôi đang làm việc ở đây trên một ứng dụng máy chủ, ngày càng lớn hơn, thậm chí tại thời điểm chúng tôi đang xem xét chia nó thành các phần khác nhau (tệp DLL), tải động khi cần và dỡ tải sau đó, để có thể xử lý các vấn đề hiệu suất.

Phần đầu tiên có ý nghĩa (chia ứng dụng cho các máy khác nhau, vì lý do hiệu suất).

Phần thứ hai (tải và dỡ thư viện) không có ý nghĩa gì, vì đây là nỗ lực thêm để thực hiện và nó sẽ không (thực sự) cải thiện mọi thứ.

Vấn đề bạn đang mô tả được giải quyết tốt hơn với các máy tính chuyên dụng, nhưng chúng sẽ không hoạt động với cùng một ứng dụng (chính).

Giải pháp cổ điển trông như thế này:

[user] [front-end] [machine1] [common resources]
                   [machine2]
                   [machine3]

Giữa các máy tính đầu cuối và máy tính, bạn có thể có những thứ bổ sung, chẳng hạn như bộ cân bằng tải và giám sát hiệu suất, và xử lý chuyên dụng trên các máy chuyên dụng rất tốt cho việc tối ưu hóa bộ nhớ cache và thông lượng.

Điều này không có nghĩa là tải / dỡ tải thêm DLL, cũng như không có gì để làm với STL.

Đó là, sử dụng STL trong nội bộ theo yêu cầu và tuần tự hóa dữ liệu của bạn giữa các yếu tố (xem grpc và bộ đệm giao thức và loại vấn đề chúng giải quyết).

Điều này cho biết, với thông tin hạn chế mà bạn cung cấp, điều này trông giống như vấn đề xy cổ điển (như @Graham đã nói).