Chúng tôi có một ứng dụng rất mô-đun với rất nhiều đối tượng được chia sẻ (.so). Một số người cho rằng trên nền tảng cấp thấp với bộ nhớ hạn chế/flash, tốt hơn nên liên kết tĩnh mọi thứ thành một tệp thực thi lớn vì các đối tượng dùng chung có chi phí cao.Đối tượng chia sẻ trên không
Ý kiến của bạn về điều này là gì?
Best Regards,
Paul
Trừ khi bộ nhớ là cực kỳ chặt chẽ, kích thước của một bản sao của những tệp này không phải là yếu tố quyết định chính. Cho rằng đây là một hệ thống nhúng, bạn có thể có một ý tưởng tốt về những ứng dụng sẽ được sử dụng thư viện của bạn và khi nào. Nếu ứng dụng của bạn mở và đóng nhiều thư viện nó tham chiếu một cách dè dặt, và bạn không bao giờ có tất cả các thư viện mở đồng thời, thì thư viện chia sẻ sẽ là một khoản tiết kiệm đáng kể trong RAM.
Yếu tố khác bạn cần xem xét là hình phạt hiệu suất. Việc mở một thư viện được chia sẻ sẽ mất một lượng thời gian nhỏ (thường là tầm thường); nếu bạn có bộ xử lý rất chậm hoặc các yêu cầu thời gian thực khó thực hiện, thư viện tĩnh sẽ không chịu phạt tải của thư viện được chia sẻ. Hồ sơ để tìm xem điều này là quan trọng hay không.
Để tổng hợp, các thư viện được chia sẻ có thể tốt hơn đáng kể so với các thư viện tĩnh trong một số trường hợp đặc biệt. Trong hầu hết các trường hợp, họ làm ít hoặc không có hại. Trong các tình huống đơn giản, bạn sẽ không nhận được lợi ích từ các thư viện được chia sẻ.
Tất nhiên, thư viện được chia sẻ sẽ tiết kiệm đáng kể trong Flash nếu bạn sử dụng cùng một thư viện. Nếu bạn sử dụng một thư viện tĩnh, một bản sao (có kích thước tương tự như thư viện được chia sẻ [1]) sẽ được biên dịch thành từng bản. Điều này rất hữu ích khi bạn đang ở trên một máy trạm PC. Nhưng bạn biết điều đó. Bạn đang làm việc với thư viện chỉ được một ứng dụng sử dụng.
[1] Sự khác biệt bộ nhớ của các tệp thư viện riêng lẻ nhỏ. Thư viện được chia sẻ thêm bảng chỉ mục và biểu tượng để dlopen(3) có thể tải thư viện. Có hay không điều này là đáng kể sẽ phụ thuộc vào trường hợp sử dụng của bạn; biên dịch cho mỗi và sau đó so sánh các kích thước để xác định kích thước nào nhỏ hơn trong Flash. Bạn sẽ phải chạy và cấu hình để xác định tiêu thụ RAM nhiều hơn; chúng phải giống nhau ngoại trừ tải ban đầu của thư viện được chia sẻ.
Có rất nhiều thư viện tất nhiên có nghĩa là nhiều siêu dữ liệu phải được lưu trữ, và cũng có một số trong đó meta-data (phần thư viện tiêu đề, vv) sẽ cần phải được được lưu trữ trong RAM khi được nạp. Nhưng sự khác biệt nên là khá không đáng kể, ngay cả trên (vừa phải hiện đại) hệ thống nhúng.
Tôi đề nghị bạn nên thử cả hai lựa chọn thay thế và đo dung lượng đã sử dụng trong cả FLASH và RAM, sau đó quyết định điều nào là tốt nhất.
Các chi phí của các thư viện chia sẻ là xấp xỉ (mỗi thư viện):
mmap và mprotect syscalls và ít nhất một lỗi trang tại thời điểm tải.vị trí độc lập Cộng với chi phí mã:
Nếu bạn có một ứng dụng dài, chi phí có thể không quan trọng đối với bạn, trừ khi bạn đang sử dụng hệ thống nhúng nhỏ. Mặt khác, nếu bạn đang viết một cái gì đó mà có thể được gọi nhiều lần cho các nhiệm vụ ngắn (như một thông dịch viên ngôn ngữ) các chi phí này có thể rất lớn. Đặt tất cả các mô-đun chuẩn trong các tệp .so riêng của chúng chứ không phải là liên kết tĩnh theo mặc định là một phần lớn lý do tại sao Perl, Python, v.v ... quá chậm để bắt đầu.
Cá nhân, tôi sẽ đi với chiến lược của việc sử dụng các module được nạp năng động như một công cụ mở rộng , không phải là một mô hình phát triển .