Tôi có thể bị thiên vị khi làm việc trong các lĩnh vực rất quan trọng về hiệu suất như xử lý hình ảnh và raytracing, nhưng tôi vẫn nói để tối ưu hóa "càng muộn càng tốt" . Cho dù các yêu cầu của bạn có hiệu suất quan trọng đến mức nào, luôn có nhiều thông tin và sự rõ ràng hơn sau khi bạn đo lường, hơn là trước, điều đó có nghĩa là ngay cả những tối ưu hóa hiệu quả nhất thường được áp dụng sau khi có được kiến thức như vậy.
Trường hợp đặc biệt
Nhưng đôi khi "càng muộn càng tốt" vẫn còn khá sớm trong một số trường hợp đặc biệt. Ví dụ, nếu chúng ta đang nói về trình kết xuất ngoại tuyến, các cấu trúc dữ liệu và kỹ thuật bạn sử dụng để đạt được hiệu suất thực sự thấm vào thiết kế cuối của người dùng. Điều này nghe có vẻ kinh tởm nhưng lĩnh vực này rất tiên tiến và quan trọng về hiệu năng đến mức người dùng chấp nhận các điều khiển kết thúc của người dùng cụ thể cho các kỹ thuật tối ưu hóa áp dụng cho một raytracer cụ thể (ví dụ: bộ nhớ đệm chiếu xạ hoặc ánh xạ photon), vì một số trong số chúng được sử dụng chờ hàng giờ để một hình ảnh được hiển thị và những người khác được sử dụng để bỏ ra số tiền khổng lồ để thuê hoặc sở hữu một trang trại kết xuất với các máy dành riêng để kết xuất. Có sự giảm đáng kể về thời gian và tiền bạc cho những người dùng đó nếu trình kết xuất ngoại tuyến cạnh tranh có thể cung cấp một mức giảm không đáng kể về thời gian kết xuất. Đây là một lĩnh vực mà thời gian giảm 5% thực sự kích thích người dùng.
Trong những trường hợp đặc biệt như vậy, bạn không thể chỉ chọn một kỹ thuật kết xuất willy-nilly và hy vọng sẽ tối ưu hóa nó sau này, vì toàn bộ thiết kế, bao gồm cả thiết kế cuối người dùng, xoay quanh cấu trúc dữ liệu và thuật toán bạn sử dụng. Bạn thậm chí không thể chỉ đi với những gì làm việc tốt cho người khác kể từ đây, với tư cách cá nhân, điểm mạnh và điểm yếu cụ thể của bạn, là yếu tố quyết định rất lớn để đưa ra giải pháp cạnh tranh. Tư duy và sự nhạy cảm của nhà phát triển chính đằng sau Arnold khác với những người làm việc trên VRay, người đã sử dụng một cách tiếp cận rất khác; họ không nhất thiết phải trao đổi địa điểm / kỹ thuật và thực hiện công việc tốt nhất (mặc dù cả hai đều là nhà lãnh đạo công nghiệp). Bạn phải loại thử nghiệm và nguyên mẫu và điểm chuẩn và tìm thấy những gì bạn ' đặc biệt giỏi trong việc đưa ra vô số các kỹ thuật tiên tiến ngoài kia nếu bạn hy vọng sẽ bán được thứ gì đó cạnh tranh sẽ thực sự bán được. Vì vậy, trong trường hợp đặc biệt này, mối quan tâm về hiệu suất di chuyển lên phía trước vì có lẽ là mối quan tâm quan trọng nhất trước khi bắt đầu phát triển.
Tuy nhiên, điều đó không nhất thiết là vi phạm tối ưu hóa "càng muộn càng tốt" , đó chỉ là "càng muộn càng tốt" là khá sớm trong những trường hợp cực đoan và kỳ dị này. Tìm ra khi nào và cả những gì không cần mối quan tâm hiệu năng sớm như vậy, nếu có, có lẽ là thách thức chính đối với nhà phát triển. Những gì không tối ưu hóa có thể là một trong những điều quý giá nhất để học và tiếp tục học hỏi trong sự nghiệp của nhà phát triển, vì bạn không thể thiếu những nhà phát triển ngây thơ muốn tối ưu hóa mọi thứ (và thật không may, ngay cả một số cựu chiến binh đã cố gắng giữ công việc của họ bằng cách nào đó mặc dù năng suất phản tác dụng của họ).
Muộn nhất có thể
Có lẽ phần khó nhất là cố gắng hiểu ý nghĩa của nó. Tôi vẫn đang học và tôi đã lập trình được gần ba thập kỷ. Nhưng đặc biệt là bây giờ trong thập kỷ thứ ba của tôi, tôi bắt đầu nhận ra điều đó không khó. Đó không phải là khoa học tên lửa, nếu bạn tập trung vào thiết kế hơn là thực hiện. Thiết kế của bạn càng rời khỏi phòng thở để tối ưu hóa phù hợp sau này mà không thay đổi thiết kế, bạn càng có thể tối ưu hóa sau này. Và càng ngày càng tăng năng suất tôi đã tìm kiếm những thiết kế như vậy đủ khả năng cho tôi phòng thở đó.
Thiết kế cung cấp phòng thở để tối ưu hóa sau này
Những kiểu thiết kế này thực sự không khó đạt được trong hầu hết các trường hợp nếu chúng ta có thể áp dụng một số "lẽ thường". Như một câu chuyện cá nhân, tôi thích nghệ thuật thị giác như một sở thích (tôi thấy phần nào giúp lập trình phần mềm cho các nghệ sĩ tự mình hiểu được nhu cầu của họ và nói ngôn ngữ của họ), và tôi đã dành thời gian vào đầu những năm 2000 bằng cách sử dụng các ứng dụng Oekaki trực tuyến như một cách nhanh chóng để vẽ nguệch ngoạc và chia sẻ công việc của tôi và kết nối với các nghệ sĩ khác.
Đặc biệt là trang web và applet yêu thích của tôi đã bị đánh lừa với các lỗi hiệu suất (bất kỳ kích thước bàn chải không tầm thường nào cũng sẽ chậm khi thu thập dữ liệu), nhưng có một cộng đồng rất tốt. Để giải quyết các vấn đề về hiệu suất, tôi đã sử dụng các cọ 1 hoặc 2 pixel nhỏ xíu và chỉ viết nguệch ngoạc công việc của mình như vậy:
Trong khi đó, tôi tiếp tục đưa ra cho tác giả các đề xuất phần mềm để cải thiện hiệu suất và anh ấy nhận thấy các đề xuất của tôi có bản chất kỹ thuật đặc biệt nói về tối ưu hóa bộ nhớ và thuật toán, v.v. Vì vậy, anh ấy thực sự hỏi tôi có phải là lập trình viên không và tôi nói có và anh ấy mời tôi làm việc về mã nguồn.
Vì vậy, tôi đã xem mã nguồn, chạy nó, lập hồ sơ và kinh hoàng là anh ấy đã thiết kế phần mềm xung quanh khái niệm "giao diện pixel trừu tượng", giống như IPixel, cuối cùng là nguyên nhân sâu xa đằng sau các điểm nóng hàng đầu cho mọi thứ năng động phân bổ và gửi cho mỗi pixel của mỗi hình ảnh. Tuy nhiên, không có cách nào thực tế để tối ưu hóa điều đó mà không xem xét lại toàn bộ thiết kế của phần mềm bởi vì thiết kế đã nhốt anh ta vào một góc mà không vượt quá tầm tối ưu vi mô tầm thường nhất khi các bản tóm tắt của chúng tôi hoạt động ở mức độ chi tiết của một pixel trừu tượng duy nhất và mọi thứ phụ thuộc vào pixel trừu tượng này.
Tôi nghĩ đó là vi phạm "lẽ thường" nhưng rõ ràng đó không phải là lẽ thường đối với nhà phát triển. Nhưng nó giống như không phải là những thứ trừu tượng ở mức độ chi tiết như vậy, trong đó ngay cả những trường hợp sử dụng cơ bản nhất cũng sẽ được tạo ra bởi hàng triệu người, như với pixel, hoặc hạt hoặc đơn vị nhỏ trong mô phỏng quân đội ginormous. Ưu tiên cho IImage(bạn có thể xử lý tất cả các định dạng hình ảnh / pixel bạn cần tại mà cồng kềnh mức tổng hợp) hoặc IParticleSystemđến IPixelhoặc IParticle, và sau đó bạn có thể đưa vào cơ bản nhất và nhanh chóng-to-ghi và đơn giản hiểu hiện thực đằng sau giao diện như vậy và có tất cả các phòng thở bạn sẽ cần phải tối ưu hóa sau này mà không cần xem xét lại toàn bộ thiết kế của phần mềm.
Và đó là mục tiêu như tôi thấy ngày nay. Không bao gồm các trường hợp đặc biệt như trình kết xuất ngoại tuyến ở trên, thiết kế có đủ phòng thở để tối ưu hóa càng muộn càng tốt, với càng nhiều thông tin nhận thức càng tốt (bao gồm các phép đo) và áp dụng bất kỳ tối ưu hóa cần thiết nào càng muộn càng tốt.
Tất nhiên, tôi không nhất thiết phải đề xuất bắt đầu sử dụng thuật toán phức tạp bậc hai trên các đầu vào dễ dàng đạt đến kích thước không tầm thường trong các trường hợp kết thúc người dùng thông thường. Ai làm điều đó? Nhưng tôi thậm chí không nghĩ rằng đó là một vấn đề lớn như vậy nếu việc thực hiện dễ dàng trao đổi sau này. Đó vẫn không phải là một sai lầm nghiêm trọng nếu bạn không phải xem xét lại bất kỳ thiết kế nào.