Sự bi quan lố bịch nhất bạn từng thấy là gì? [đóng cửa]

Chúng ta đều biết rằng tối ưu hóa sớm là gốc rễ của mọi tội lỗi vì nó dẫn đến mã không thể đọc được / không thể nhầm lẫn. Tệ hơn nữa là sự bi quan, khi ai đó thực hiện "tối ưu hóa" bởi vì họ nghĩ rằng nó sẽ nhanh hơn, nhưng cuối cùng lại chậm hơn, cũng như bị lỗi, không thể nhận ra, v.v ... Ví dụ nực cười nhất về điều này mà bạn đã thấy là gì ?

Trong một dự án cũ, chúng tôi đã thừa hưởng một số lập trình viên hệ thống nhúng (nếu không xuất sắc), người có kinh nghiệm Z-8000 lớn.

Môi trường mới của chúng tôi là Sparc Solaris 32-bit.

Một trong những kẻ đã đi và thay đổi tất cả các int thành quần short để tăng tốc mã của chúng tôi, vì lấy 16 bit từ RAM nhanh hơn lấy 32 bit.

Tôi đã phải viết một chương trình demo để chỉ ra rằng việc lấy các giá trị 32 bit trên hệ thống 32 bit nhanh hơn lấy các giá trị 16 bit và giải thích rằng để lấy giá trị 16 bit, CPU phải tạo ra một chiều rộng 32 bit truy cập bộ nhớ và sau đó che dấu hoặc dịch chuyển các bit không cần thiết cho giá trị 16 bit.

Tôi nghĩ rằng cụm từ "tối ưu hóa sớm là gốc rễ của mọi tội lỗi" là cách sử dụng. Đối với nhiều dự án, nó đã trở thành một cái cớ để không tính đến hiệu suất cho đến khi muộn trong một dự án.

Cụm từ này thường là một cái nạng cho mọi người để tránh làm việc. Tôi thấy cụm từ này được sử dụng khi mọi người thực sự nên nói "Gee, chúng tôi thực sự không nghĩ về điều đó ngay từ đầu và không có thời gian để giải quyết nó ngay bây giờ".

Tôi đã thấy nhiều ví dụ "lố bịch" hơn về các vấn đề hiệu suất câm so với các ví dụ về các vấn đề được đưa ra do "bi quan"

• Đọc cùng khóa đăng ký hàng nghìn (hoặc 10 nghìn) lần trong khi khởi chạy chương trình.
• Tải cùng một DLL hàng trăm hoặc hàng nghìn lần
• Lãng phí byte lớn của bộ nhớ bằng cách giữ đường dẫn đầy đủ đến các tệp không cần thiết
• Không tổ chức cấu trúc dữ liệu để chúng chiếm nhiều bộ nhớ hơn mức cần thiết
• Định cỡ tất cả các chuỗi lưu trữ tên tệp hoặc đường dẫn đến MAX_PATH
• Bỏ phiếu miễn phí cho điều có sự kiện, cuộc gọi lại hoặc cơ chế thông báo khác

Điều tôi nghĩ là một tuyên bố tốt hơn là: "tối ưu hóa mà không đo lường và hiểu không hoàn toàn tối ưu hóa - đó chỉ là thay đổi ngẫu nhiên".

Công việc hiệu suất tốt là tốn thời gian - thường là do sự phát triển của tính năng hoặc thành phần.

Cơ sở dữ liệu là sân chơi bi quan.

Yêu thích bao gồm:

• Chia bảng thành nhiều phần (theo phạm vi ngày, phạm vi chữ cái, v.v.) vì nó "quá lớn".
• Tạo một bảng lưu trữ cho các bản ghi đã nghỉ hưu, nhưng tiếp tục UNION nó với bảng sản xuất.
• Sao chép toàn bộ cơ sở dữ liệu theo (bộ phận / khách hàng / sản phẩm / v.v.)
• Chống lại việc thêm các cột vào một chỉ mục vì nó làm cho nó quá lớn.
• Tạo nhiều bảng tóm tắt vì tính toán lại từ dữ liệu thô quá chậm.
• Tạo các cột với các trường con để tiết kiệm không gian.
• Không chuẩn hóa thành các trường như là một mảng.

Đó là trên đỉnh đầu của tôi.

Tôi nghĩ rằng không có quy tắc tuyệt đối: một số thứ được tối ưu hóa tốt nhất, và một số thì không.

Ví dụ, tôi làm việc trong một công ty nơi chúng tôi nhận được các gói dữ liệu từ các vệ tinh. Mỗi gói có giá rất nhiều tiền, vì vậy tất cả các dữ liệu được tối ưu hóa cao (nghĩa là đóng gói). Ví dụ: vĩ độ / kinh độ không được gửi dưới dạng giá trị tuyệt đối (phao), mà là độ lệch so với góc "tây bắc" của vùng "hiện tại". Chúng tôi đã phải giải nén tất cả dữ liệu trước khi nó có thể được sử dụng. Nhưng tôi nghĩ rằng đây không phải là bi quan, đó là tối ưu hóa thông minh để giảm chi phí truyền thông.

Mặt khác, các kiến ​​trúc sư phần mềm của chúng tôi đã quyết định rằng dữ liệu được giải nén phải được định dạng thành một tài liệu XML rất dễ đọc và được lưu trữ trong cơ sở dữ liệu của chúng tôi (trái ngược với việc mỗi trường được lưu trữ trong một cột tương ứng). Ý tưởng của họ là "XML là tương lai", "không gian đĩa là rẻ" và "bộ xử lý là rẻ", do đó không cần phải tối ưu hóa bất cứ điều gì. Kết quả là các gói 16 byte của chúng tôi đã được chuyển thành các tài liệu 2kB được lưu trữ trong một cột và đối với các truy vấn đơn giản, chúng tôi phải tải megabyte tài liệu XML vào bộ nhớ! Chúng tôi đã nhận được hơn 50 gói mỗi giây, vì vậy bạn có thể tưởng tượng hiệu suất trở nên khủng khiếp như thế nào (BTW, công ty đã phá sản).

Vì vậy, một lần nữa, không có quy tắc tuyệt đối. Vâng, đôi khi tối ưu hóa quá sớm là một sai lầm. Nhưng đôi khi phương châm "cpu / không gian đĩa / bộ nhớ là rẻ" là gốc rễ thực sự của mọi tội lỗi.

Chúa ơi, tôi nghĩ rằng tôi đã thấy tất cả. Thường xuyên hơn không phải là một nỗ lực để khắc phục các vấn đề về hiệu suất bởi một người quá lười biếng để khắc phục sự cố dẫn đến NGUYÊN NHÂN của những vấn đề về hiệu suất đó hoặc thậm chí nghiên cứu xem có thực sự có vấn đề về hiệu suất hay không. Trong nhiều trường hợp này, tôi tự hỏi liệu đó không chỉ là trường hợp người đó muốn thử một công nghệ cụ thể và tuyệt vọng tìm kiếm một chiếc đinh phù hợp với cây búa mới sáng bóng của họ.

Đây là một ví dụ gần đây:

Kiến trúc sư dữ liệu đến với tôi với một đề xuất phức tạp để phân vùng theo chiều dọc một bảng chính trong một ứng dụng khá lớn và phức tạp. Anh ta muốn biết loại nỗ lực phát triển nào sẽ là cần thiết để điều chỉnh cho sự thay đổi. Cuộc trò chuyện diễn ra như sau:

Tôi: Tại sao bạn xem xét điều này? Vấn đề bạn đang cố gắng giải quyết là gì?

Ngài: Bảng X quá rộng, chúng tôi đang phân vùng nó vì lý do hiệu năng.

Tôi: Điều gì khiến bạn nghĩ nó quá rộng?

Ngài: Nhà tư vấn nói rằng có quá nhiều cột trong một bảng.

Tôi: Và điều này có ảnh hưởng đến hiệu suất?

Ngài: Có, người dùng đã báo cáo sự chậm lại không liên tục trong mô-đun XYZ của ứng dụng.

Tôi: Làm thế nào để bạn biết chiều rộng của bảng là nguồn gốc của vấn đề?

Ngài: Đó là bảng chính được sử dụng bởi mô-đun XYZ và nó giống như 200 cột. Nó phải là vấn đề.

Tôi (Giải thích): Nhưng cụ thể mô-đun XYZ sử dụng hầu hết các cột trong bảng đó và các cột mà nó sử dụng là không thể đoán trước được vì người dùng định cấu hình ứng dụng để hiển thị dữ liệu họ muốn hiển thị từ bảng đó. Có khả năng 95% thời gian chúng tôi sẽ kết hợp tất cả các bảng lại với nhau dù điều đó sẽ làm giảm hiệu suất.

Ngài: Nhà tư vấn nói nó quá rộng và chúng ta cần thay đổi nó.

Tôi: ai là người tư vấn này? Tôi không biết chúng tôi đã thuê một nhà tư vấn, họ cũng không nói chuyện với nhóm phát triển.

Ngài: Chà, chúng tôi chưa thuê họ. Đây là một phần của một đề xuất mà họ đưa ra, nhưng họ khẳng định chúng tôi cần phải kiến ​​trúc lại cơ sở dữ liệu này.

Tôi: Uh huh. Vì vậy, nhà tư vấn bán dịch vụ thiết kế lại cơ sở dữ liệu nghĩ rằng chúng tôi cần thiết kế lại cơ sở dữ liệu ....

Cuộc trò chuyện đã diễn ra như thế này. Sau đó, tôi đã xem xét lại bảng này và xác định rằng nó có thể được thu hẹp với một số chuẩn hóa đơn giản mà không cần các chiến lược phân vùng kỳ lạ. Điều này, tất nhiên hóa ra là một điểm cần thiết khi tôi điều tra các vấn đề về hiệu suất (trước đây không được báo cáo) và theo dõi chúng theo hai yếu tố:

1. Thiếu chỉ mục trên một vài cột quan trọng.
2. Một vài nhà phân tích dữ liệu giả mạo đã định kỳ khóa các bảng chính (bao gồm cả bảng "quá rộng") bằng cách truy vấn trực tiếp cơ sở dữ liệu sản xuất với MSAccess.

Tất nhiên, kiến ​​trúc sư vẫn đang thúc đẩy phân vùng dọc của bảng treo vào vấn đề meta "quá rộng". Anh ta thậm chí còn củng cố trường hợp của mình bằng cách nhận được đề xuất từ ​​một nhà tư vấn cơ sở dữ liệu khác, người có thể xác định chúng tôi cần thay đổi thiết kế lớn cho cơ sở dữ liệu mà không cần nhìn vào ứng dụng hoặc chạy bất kỳ phân tích hiệu suất nào.

Tôi đã thấy mọi người sử dụng alphadrive-7 để hoàn toàn ủ CHX-LT. Đây là một thực tế không phổ biến. Cách thực hành phổ biến hơn là khởi tạo biến áp ZT để giảm bộ đệm (do khả năng chống quá tải ròng lớn hơn) và tạo ra các biểu thức java theo kiểu.

Hoàn toàn bi quan!

Tôi thừa nhận không có gì làm rung chuyển Trái đất, nhưng tôi đã bắt gặp những người sử dụng StringBuffer để nối các Chuỗi bên ngoài một vòng lặp trong Java. Nó là một cái gì đó đơn giản như biến

String msg = "Count = " + count + " of " + total + ".";

vào

StringBuffer sb = new StringBuffer("Count = ");
sb.append(count);
sb.append(" of ");
sb.append(total);
sb.append(".");
String msg = sb.toString();

Nó được sử dụng khá phổ biến để sử dụng kỹ thuật trong một vòng lặp, bởi vì nó nhanh hơn đáng kể. Vấn đề là, StringBuffer đã được đồng bộ hóa, vì vậy thực sự có thêm chi phí nếu bạn chỉ nối một vài Chuỗi. (Không đề cập đến sự khác biệt là hoàn toàn không đáng kể trên thang đo này.) Hai điểm khác về thực hành này:

1. StringBuilder không được đồng bộ hóa, do đó, nên được ưu tiên hơn StringBuffer trong trường hợp mã của bạn không thể được gọi từ nhiều luồng.
2. Các trình biên dịch Java hiện đại sẽ biến việc nối chuỗi có thể đọc thành mã byte được tối ưu hóa cho bạn khi nào cũng phù hợp.

Tôi đã từng thấy một cơ sở dữ liệu MSSQL sử dụng bảng 'Root'. Bảng gốc có bốn cột: GUID (mã định danh duy nhất), ID (int), LastModDate (datetime) và CreateDate (datetime). Tất cả các bảng trong cơ sở dữ liệu là Foreign Key'd vào bảng Root. Bất cứ khi nào một hàng mới được tạo trong bất kỳ bảng nào trong db, bạn phải sử dụng một vài thủ tục được lưu trữ để chèn một mục trong bảng Root trước khi bạn có thể đến bảng thực tế mà bạn quan tâm (thay vì cơ sở dữ liệu thực hiện công việc cho bạn với một vài kích hoạt đơn giản kích hoạt).

Điều này tạo ra một mớ hỗn độn vô dụng và đau đầu, yêu cầu bất cứ điều gì được viết trên đó để sử dụng sprocs (và loại bỏ hy vọng của tôi về việc giới thiệu LINQ cho công ty. Có thể nhưng không đáng để đau đầu), và không cần phải đau đầu ' thậm chí hoàn thành những gì nó phải làm.

Nhà phát triển đã chọn đường dẫn này bảo vệ nó theo giả định rằng điều này đã tiết kiệm hàng tấn không gian vì chúng tôi không sử dụng Hướng dẫn trên chính các bảng (nhưng ... không phải là GUID được tạo trong bảng Root cho mỗi hàng chúng tôi tạo ra?) , cải thiện hiệu suất bằng cách nào đó và làm cho "dễ dàng" kiểm toán các thay đổi đối với cơ sở dữ liệu.

Ồ, và sơ đồ cơ sở dữ liệu trông giống như một con nhện đột biến từ địa ngục.

Làm thế nào về POBI - bi quan rõ ràng bằng ý định?

Collegue của tôi trong những năm 90 đã mệt mỏi khi bị CEO đá vào mông chỉ vì CEO đã dành ngày đầu tiên cho mỗi bản phát hành phần mềm ERP (một tùy chỉnh) với các vấn đề về hiệu suất trong các chức năng mới. Ngay cả khi các chức năng mới đã nghiền nát hàng gigabyte và biến điều không thể thành có thể, anh ta luôn tìm thấy một số chi tiết, hoặc thậm chí là vấn đề lớn, để than vãn. Anh ta tin rằng biết nhiều về lập trình và có những cú đá của mình bằng cách đá lừa lập trình viên.

Do bản chất bất tài của những lời chỉ trích (anh ta là CEO, không phải là nhân viên IT), đồng nghiệp của tôi không bao giờ quản lý để làm cho đúng. Nếu bạn không gặp vấn đề về hiệu suất, bạn không thể loại bỏ nó ...

Cho đến khi có một bản phát hành, anh ta đã đưa rất nhiều lệnh gọi hàm Delay (200) (đó là Delphi) vào mã mới. Chỉ mất 20 phút sau khi phát trực tiếp, và anh ta được lệnh xuất hiện trong văn phòng của CEO để trực tiếp nhận những lời lăng mạ quá hạn của mình.

Chỉ có điều bất thường cho đến nay là đồng nghiệp của tôi câm lặng khi anh ta quay lại, mỉm cười, đùa giỡn, đi ra ngoài mua một hoặc hai BigMac trong khi anh ta thường đá bàn, châm chọc về CEO và công ty, và dành phần còn lại của ngày để chết. .

Đương nhiên, đồng nghiệp của tôi bây giờ nghỉ ngơi một hoặc hai ngày tại bàn làm việc của anh ấy, cải thiện kỹ năng nhắm của anh ấy trong Quake - sau đó vào ngày thứ hai hoặc thứ ba, anh ấy đã xóa các cuộc gọi Trì hoãn, xây dựng lại và phát hành một "bản vá khẩn cấp" mà anh ấy đã truyền bá rằng anh ấy đã dành 2 ngày 1 đêm để sửa các lỗ hổng hiệu suất.

Đây là lần đầu tiên (và duy nhất) mà CEO độc ác nói "công việc tuyệt vời!" cho anh ta. Đó là tất cả những gì được tính, phải không?

Đây là POBI thực sự.

Nhưng nó cũng là một loại tối ưu hóa quy trình xã hội, vì vậy nó ổn 100%.

Tôi nghĩ.

"Độc lập cơ sở dữ liệu". Điều này có nghĩa là không có procs được lưu trữ, kích hoạt, vv - thậm chí không có bất kỳ khóa ngoại nào.

var stringBuilder = new StringBuilder();
stringBuilder.Append(myObj.a + myObj.b + myObj.c + myObj.d);
string cat = stringBuilder.ToString();

Sử dụng tốt nhất một StringBuilder mà tôi từng thấy.

Sử dụng biểu thức chính để phân tách chuỗi khi chuỗi đơn giản.split đủ

Tôi biết rất muộn về chủ đề này, nhưng tôi đã thấy điều này gần đây:

bool isFinished = GetIsFinished();

switch (isFinished)
{
    case true:
        DoFinish();
        break;

    case false:
        DoNextStep();
        break;

    default:
        DoNextStep();
}

Vâng, chỉ trong trường hợp một boolean có một số giá trị bổ sung ...

Ví dụ tồi tệ nhất tôi có thể nghĩ là một cơ sở dữ liệu nội bộ tại công ty của tôi có chứa thông tin về tất cả nhân viên. Nó nhận được cập nhật hàng đêm từ HR và có dịch vụ web ASP.NET trên đầu trang. Nhiều ứng dụng khác sử dụng dịch vụ web để điền vào những thứ như trường tìm kiếm / thả xuống.

Điều bi quan là nhà phát triển nghĩ rằng các cuộc gọi lặp lại cho dịch vụ web sẽ quá chậm để thực hiện các truy vấn SQL lặp lại. Vậy anh ấy đã làm gì? Sự kiện bắt đầu ứng dụng đọc trong toàn bộ cơ sở dữ liệu và chuyển đổi tất cả thành các đối tượng trong bộ nhớ, được lưu trữ vô thời hạn cho đến khi nhóm ứng dụng được tái chế. Mã này rất chậm, sẽ mất 15 phút để tải trong ít hơn 2000 nhân viên. Nếu bạn vô tình tái chế nhóm ứng dụng trong ngày, có thể mất 30 phút trở lên, vì mỗi yêu cầu dịch vụ web sẽ bắt đầu tải lại đồng thời nhiều lần. Vì lý do này, những người tuyển dụng mới sẽ không xuất hiện trong cơ sở dữ liệu vào ngày đầu tiên khi tài khoản của họ được tạo và do đó sẽ không thể truy cập hầu hết các ứng dụng nội bộ trong vài ngày đầu tiên, vặn ngón tay cái.

Mức độ bi quan thứ hai là người quản lý phát triển không muốn chạm vào nó vì sợ phá vỡ các ứng dụng phụ thuộc, nhưng chúng tôi vẫn tiếp tục phát sinh các ứng dụng quan trọng trên toàn công ty do thiết kế kém của một thành phần đơn giản như vậy.

Không ai có vẻ đã đề cập đến việc sắp xếp, vì vậy tôi sẽ.

Một vài lần khác nhau, tôi đã phát hiện ra rằng ai đó đã tạo ra một bong bóng bằng tay, bởi vì tình huống "không yêu cầu" một cuộc gọi đến thuật toán quicksort "quá lạ mắt" đã tồn tại. Nhà phát triển đã được bão hòa khi bong bóng thủ công của họ hoạt động đủ tốt trên mười hàng dữ liệu mà họ đang sử dụng để thử nghiệm. Nó cũng không đi đến đâu sau khi khách hàng đã thêm một vài nghìn hàng.

Tôi đã từng làm việc trên một ứng dụng chứa đầy mã như thế này:

 1 tuple *FindTuple( DataSet *set, int target ) {
 2     tuple *found = null;
 3     tuple *curr = GetFirstTupleOfSet(set);
 4     while (curr) {
 5         if (curr->id == target)
 6             found = curr;
 7         curr = GetNextTuple(curr);
 8     }
 9     return found;
10 }

Chỉ cần xóa found, quay lại nullở cuối và thay đổi dòng thứ sáu thành:

            return curr;

Nhân đôi hiệu suất ứng dụng.

Tôi đã từng phải cố gắng sửa đổi mã bao gồm các đá quý này trong lớp Hằng

public static String COMMA_DELIMINATOR=",";
public static String COMMA_SPACE_DELIMINATOR=", ";
public static String COLIN_DELIMINATOR=":";

Mỗi trong số này đã được sử dụng nhiều lần trong phần còn lại của ứng dụng cho các mục đích khác nhau. COMMA_DELIMINATOR xả rác mã với hơn 200 sử dụng trong 8 gói khác nhau.

Số lớn mọi thời đại mà tôi gặp phải nhiều lần trong phần mềm đường phố:

Không sử dụng các tính năng của DBMS vì lý do "tính di động" vì "chúng tôi có thể muốn chuyển sang nhà cung cấp khác sau".

Đọc khẩu hình của tôi. Đối với bất kỳ công việc đường phố nào: NÓ S H KHÔNG HẠNH PHÚC!

Tôi đã có một đồng nghiệp đang cố gắng đánh lừa trình tối ưu hóa trình biên dịch C của chúng tôi và viết lại mã thường xuyên mà chỉ anh ta mới đọc được. Một trong những thủ thuật yêu thích của anh ấy là thay đổi một phương thức dễ đọc như (tạo một số mã):

int some_method(int input1, int input2) {
    int x;
    if (input1 == -1) {
        return 0;
    }
    if (input1 == input2) {
        return input1;
    }
    ... a long expression here ...
    return x;
}

vào đây:

int some_method() {
    return (input == -1) ? 0 : (input1 == input2) ? input 1 :
           ... a long expression ...
           ... a long expression ...
           ... a long expression ...
}

Đó là, dòng đầu tiên của một phương thức có thể đọc được sẽ trở thành " return" và tất cả các logic khác sẽ được thay thế bằng các biểu thức bậc ba lồng nhau sâu sắc. Khi bạn cố gắng tranh luận về việc làm thế nào là không thể hiểu được, anh ta sẽ chỉ ra một thực tế là đầu ra lắp ráp phương pháp của anh ta ngắn hơn ba hoặc bốn hướng dẫn lắp ráp. Nó không nhất thiết phải nhanh hơn nhưng nó luôn nhỏ xíu chút ngắn hơn. Đây là một hệ thống nhúng mà việc sử dụng bộ nhớ đôi khi có vấn đề, nhưng có những tối ưu hóa dễ dàng hơn nhiều có thể được thực hiện so với điều này sẽ khiến mã có thể đọc được.

Sau đó, vì lý do nào đó, anh ta quyết định rằng ptr->structElementquá khó đọc, vì vậy anh ta bắt đầu thay đổi tất cả những điều này thành (*ptr).structElementlý thuyết rằng nó cũng dễ đọc hơn và nhanh hơn.

Biến mã có thể đọc thành mã không thể đọc được để cải thiện tối đa 1% và đôi khi mã thực sự chậm hơn.

Trong một trong những công việc đầu tiên của tôi với tư cách là một nhà phát triển chính thức, tôi đã tiếp quản một dự án cho một chương trình đang gặp vấn đề về quy mô. Nó sẽ hoạt động hợp lý tốt trên các tập dữ liệu nhỏ, nhưng sẽ hoàn toàn sụp đổ khi được cung cấp một lượng lớn dữ liệu.

Khi tôi đi sâu vào, tôi thấy rằng lập trình viên ban đầu đã tìm cách tăng tốc mọi thứ bằng cách song song phân tích - khởi chạy một luồng mới cho mỗi nguồn dữ liệu bổ sung. Tuy nhiên, anh ta đã mắc một sai lầm ở chỗ tất cả các luồng đều yêu cầu tài nguyên dùng chung, trong đó chúng đang bế tắc. Tất nhiên, tất cả lợi ích của đồng thời biến mất. Hơn nữa, nó đã đánh sập hầu hết các hệ thống để khởi chạy hơn 100 luồng chỉ để có tất cả trừ một trong số chúng bị khóa. Máy dev của tôi là một ngoại lệ ở chỗ nó lướt qua bộ dữ liệu 150 nguồn trong khoảng 6 giờ.

Vì vậy, để khắc phục nó, tôi đã loại bỏ các thành phần đa luồng và dọn sạch I / O. Không có thay đổi nào khác, thời gian thực hiện trên bộ dữ liệu 150 nguồn giảm xuống dưới 10 phút trên máy của tôi và từ vô cực đến dưới nửa giờ trên máy công ty trung bình.

Tôi cho rằng tôi có thể cung cấp đá quý này:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    // Find out how many bytes our value uses
    // so we don't do any uneeded work.
    if (value & 0xffff0000)
    {
        if ((value & 0xff000000) == 0)
            tmp = 3;
        else
            tmp = 4;
    }
    else if (value & 0x0000ff00)
        tmp = 2;

    switch (tmp)
    {
        case 4:
            ISQRT_INNER(15);
            ISQRT_INNER(14);
            ISQRT_INNER(13);
            ISQRT_INNER(12);
        case 3:
            ISQRT_INNER(11);
            ISQRT_INNER(10);
            ISQRT_INNER( 9);
            ISQRT_INNER( 8);
        case 2:
            ISQRT_INNER( 7);
            ISQRT_INNER( 6);
            ISQRT_INNER( 5);
            ISQRT_INNER( 4);
        case 1:
            ISQRT_INNER( 3);
            ISQRT_INNER( 2);
            ISQRT_INNER( 1);
            ISQRT_INNER( 0);
    }
#undef ISQRT_INNER
    return root;
}

Vì căn bậc hai đã được tính toán ở một nơi rất nhạy cảm, tôi có nhiệm vụ tìm kiếm một cách để làm cho nó nhanh hơn. Việc tái cấu trúc nhỏ này đã giảm thời gian thực hiện xuống một phần ba (đối với sự kết hợp giữa phần cứng và trình biên dịch được sử dụng, YMMV):

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    ISQRT_INNER (15);
    ISQRT_INNER (14);
    ISQRT_INNER (13);
    ISQRT_INNER (12);
    ISQRT_INNER (11);
    ISQRT_INNER (10);
    ISQRT_INNER ( 9);
    ISQRT_INNER ( 8);
    ISQRT_INNER ( 7);
    ISQRT_INNER ( 6);
    ISQRT_INNER ( 5);
    ISQRT_INNER ( 4);
    ISQRT_INNER ( 3);
    ISQRT_INNER ( 2);
    ISQRT_INNER ( 1);
    ISQRT_INNER ( 0);

#undef ISQRT_INNER
    return root;
}

Tất nhiên có cả hai cách nhanh hơn và tốt hơn để làm điều này, nhưng tôi nghĩ đó là một ví dụ khá gọn gàng về sự bi quan.

Chỉnh sửa: Hãy nghĩ về nó, vòng lặp không được kiểm soát thực sự cũng là một bi quan gọn gàng. Đào qua điều khiển phiên bản, tôi cũng có thể trình bày giai đoạn tái cấu trúc thứ hai, hoạt động thậm chí còn tốt hơn so với ở trên:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1 << 30, root = 0;

    while (tmp != 0)
    {
        if (value >= root + tmp) {
            value -= root + tmp;
            root += tmp << 1;
        }
        root >>= 1;
        tmp >>= 2;
    }

    return root;
}

Đây chính xác là cùng một thuật toán, mặc dù cách triển khai hơi khác, vì vậy tôi cho rằng nó đủ điều kiện.

Điều này có thể ở cấp độ cao hơn những gì bạn đã theo đuổi, nhưng sửa nó (nếu bạn được phép) cũng liên quan đến mức độ đau đớn cao hơn:

Nhấn mạnh vào việc cuộn một Trình quản lý quan hệ đối tượng / Lớp truy cập dữ liệu thay vì sử dụng một trong các thư viện trưởng thành, đã được kiểm tra, đã được thiết lập ngoài đó (ngay cả sau khi chúng được chỉ ra cho bạn).

Tất cả các ràng buộc khóa ngoài đã bị xóa khỏi cơ sở dữ liệu, vì nếu không sẽ có rất nhiều lỗi.

Điều này không chính xác phù hợp với câu hỏi, nhưng dù sao tôi cũng sẽ đề cập đến nó một câu chuyện cảnh báo. Tôi đang làm việc trên một ứng dụng phân tán đang chạy chậm và bay xuống DC để tham gia một cuộc họp chủ yếu nhằm giải quyết vấn đề. Trưởng dự án bắt đầu phác thảo một kiến ​​trúc lại nhằm giải quyết sự chậm trễ. Tôi tình nguyện rằng tôi đã thực hiện một số phép đo vào cuối tuần qua, cô lập nút cổ chai thành một phương pháp duy nhất. Hóa ra có một bản ghi bị thiếu trong một tra cứu cục bộ, khiến ứng dụng phải đến một máy chủ từ xa trên mỗi giao dịch. Bằng cách thêm bản ghi trở lại cửa hàng địa phương, độ trễ đã được loại bỏ - vấn đề đã được giải quyết. Lưu ý kiến ​​trúc lại sẽ không khắc phục vấn đề.

Kiểm tra trước MỌI thao tác javascript xem đối tượng bạn đang hoạt động có tồn tại không.

if (myObj) { //or its evil cousin, if (myObj != null) {
    label.text = myObj.value; 
    // we know label exists because it has already been 
    // checked in a big if block somewhere at the top
}

Vấn đề của tôi với loại mã này dường như không ai quan tâm nếu nó không tồn tại? Chỉ cần làm gì? Đừng đưa ra phản hồi cho người dùng?

Tôi đồng ý rằng các Object expectedlỗi gây phiền nhiễu, nhưng đây không phải là giải pháp tốt nhất cho điều đó.

Làm thế nào về chủ nghĩa cực đoan YAGNI. Đó là một hình thức bi quan sớm. Có vẻ như bất cứ khi nào bạn áp dụng YAGNI, sau đó bạn sẽ cần nó, dẫn đến nỗ lực để thêm nó gấp 10 lần so với khi bạn đã thêm nó vào lúc đầu. Nếu bạn tạo ra một chương trình thành công thì tỷ lệ cược là BẠN ĐANG CẦN NÓ. Nếu bạn đã quen với việc tạo ra các chương trình có cuộc sống nhanh chóng thì hãy tiếp tục thực hành YAGNI vì sau đó tôi cho rằng YAGNI.

Không chính xác tối ưu hóa sớm - nhưng chắc chắn là sai lầm - điều này đã được đọc trên trang web BBC, từ một bài viết thảo luận về Windows 7.

Ông Curran nói rằng nhóm Microsoft Windows đã nghiên cứu mọi khía cạnh của hệ điều hành để cải thiện. "Chúng tôi đã có thể tắt 400 mili giây trong thời gian tắt máy bằng cách cắt nhẹ nhạc tắt máy WAV.

Bây giờ, tôi chưa dùng thử Windows 7, vì vậy tôi có thể sai, nhưng tôi sẵn sàng đặt cược rằng có những vấn đề khác quan trọng hơn là mất bao lâu để tắt máy. Rốt cuộc, một khi tôi thấy thông báo 'Tắt Windows', màn hình sẽ tắt và tôi đang bỏ đi - 400 mili giây đó có lợi cho tôi như thế nào?

Ai đó trong bộ phận của tôi đã từng viết một lớp chuỗi. Một giao diện như thế CString, nhưng không có sự phụ thuộc của Windows.

Một "tối ưu hóa" họ đã làm là không phân bổ thêm bộ nhớ nào cần thiết. Rõ ràng không nhận ra rằng các lớp lý do như std::stringphân bổ bộ nhớ dư thừa là để một chuỗi các +=hoạt động có thể chạy trong thời gian O (n).

Thay vào đó, mỗi +=cuộc gọi đều buộc phải phân bổ lại, điều này đã biến các phần phụ lặp đi lặp lại thành thuật toán O (n²) của họa sĩ .

Một đồng nghiệp cũ của tôi ( thực tế là một soab ) đã được chỉ định để xây dựng một mô-đun mới cho Java ERP của chúng tôi cần thu thập và phân tích dữ liệu của khách hàng (ngành bán lẻ). Anh quyết định chia MỌI trường Lịch / Ngày trong các thành phần của nó (giây, phút, giờ, ngày, tháng, năm, ngày trong tuần, bimester, tam cá nguyệt (!)) Bởi vì "tôi sẽ truy vấn 'mọi thứ hai' như thế nào?"

Không xúc phạm bất cứ ai, nhưng tôi vừa chấm điểm một bài tập (java) có cái này

import java.lang.*;