2012-04-26 20 views

Trả lời

9

Có, vì hầu hết các tối ưu hóa được thực hiện tại thời gian chạy bởi JVM, trình biên dịch đang làm rất ít liên quan đến tối ưu hóa. Do đó, mã được biên dịch với trình biên dịch Java cũ vẫn sẽ được hưởng lợi từ JVM mới.

Tuy nhiên, có một số tối ưu hóa được thực hiện tại thời gian biên dịch, như thay thế các liên kết String liên tiếp với StringBuilder.

+0

Xin chào Tomasz, cảm ơn câu trả lời. Bạn có con trỏ nào để đọc tài liệu nêu trên không? Một cái gì đó chính thức từ Sun hoặc Oracle sẽ rất tuyệt vời. – bungrudi

+0

@ bungrudi: thật không may, nó chỉ là một kiến ​​thức phổ biến từ SO. Nhưng có lẽ ai đó sẽ chỉ ra các nguồn lực khó khăn? –

+0

+1 Trình biên dịch 'javac' không chỉ làm tối ưu hóa rất ít, những gì không thay đổi nhiều kể từ Java 1.4. Việc sử dụng StringBuilder thay vì cho StringBuffer đã được thêm vào trong Java 5.0 (2004) nhưng sự khác biệt thường rất nhỏ. –

1

Gần như tất cả các tối ưu hóa trong java xảy ra trong jit và do đó chỉ phụ thuộc vào phiên bản jvm đang chạy ứng dụng. Trình biên dịch bytecode javac chỉ phát ra các bytecode thẳng nhất có thể. Tôi không nghĩ rằng có bất kỳ tối ưu hóa ở giai đoạn này, ngoại trừ có lẽ cho chuỗi nối bằng cách sử dụng StringBuilder/StringBuffer.

Java 6 trở lên có thể sử dụng bytecode verifier nhanh hơn và đơn giản hơn cho các lớp được biên dịch với phiên bản đích 6. Trình biên dịch javac tạo thông tin bổ sung về các loại dữ liệu trong mỗi ngăn xếp, mà trình xác minh phải xác thực. Trong các phiên bản trước, người xác minh đã phải suy ra những loại phức tạp hơn. Thay đổi này sẽ chỉ tăng tốc độ tải các lớp và sẽ không có tác động khi thực sự thực thi bytecode.

Tôi nghĩ một thay đổi khác đối với mã byte trong phiên bản 5 hoặc 6 là nhóm không đổi trong tệp lớp có thể tham chiếu các lớp và giao diện. Một lần nữa, điều này có lẽ chỉ ảnh hưởng đến tải lớp.

0

Không chỉ đơn giản là sẽ đạt được hiệu suất lớn, nhưng ngay cả giữa các phiên bản Java 6 có sự khác biệt lớn. Tôi đã theo dõi các bản phát hành nhỏ của Java 6 trong khoảng thời gian 18 tháng và thấy 15-20% tăng tốc chỉ từ đó.

Java 7 cũng đã xuất hiện và là phiên bản sản xuất được ưu tiên - có lý do nào khiến bạn không muốn chuyển sang phiên bản đó không?

Ồ, và một điều cuối cùng. Nếu bạn cần chứng minh lợi ích cho việc quản lý, thì bạn nên đọc rất nhiều về việc đo lường hiệu suất của các ứng dụng Java. Tôi có một bài viết trong số tháng 5/tháng 6 năm 2012 sắp tới của tạp chí Java của Oracle, đó là một thực tế 101 nếu bạn cần nó. Đó là một chủ đề rất trơn, vì vậy bạn nên làm rất nhiều việc đọc hoặc bạn có thể nhận được những con số rất gây hiểu nhầm.

+0

Ứng dụng này là ứng dụng kế thừa WebSphere 6 (Java 1.4) mà chúng tôi hiện đang chuyển sang WebSphere 7. JDK 'đi kèm' là 1.6.0_xx và chúng tôi không có thời gian rảnh rỗi để cố gắng thay đổi nó thành Java 7 (ít nhất là bây giờ). Tôi đang háo hức chờ đợi bài viết của bạn. – bungrudi

2

Như Tomasz Nurkiewicz chỉ ra hầu hết các tối ưu hóa được thực hiện bởi trình biên dịch JIT và bạn sẽ thấy lợi ích hiệu suất bằng cách chạy trên java 6 thay vì java 1.4. Tuy nhiên, điều này không đảm bảo bạn sẽ trích xuất các kết quả tốt nhất. Bạn vẫn có thể bỏ lỡ các lợi ích nếu bạn đang sử dụng các biến thể chậm hơn (cũ hơn) của cấu trúc dữ liệu. ví dụ. StringBuffer thay vì StringBuilder, Vector thay vì LinkedList, Hashtable thay vì HashMap, và cứ thế ...

Bạn cũng có thể xem xét biên dịch với cờ -deprecated cho javac. Bạn có thể muốn thay thế các phương pháp không dùng nữa vì chúng thường có nghĩa là có một lựa chọn thay thế tốt hơn để đạt được điều tương tự.

+0

con trỏ đẹp trên cờ -deprecated. 1 cho điều này. – bungrudi