Tên biến có ảnh hưởng đến hiệu suất của các trang web?


11

Tên biến có ảnh hưởng đến hiệu suất trang web? Tôi biết điều này sẽ là con số rất thấp, nhưng vẫn có ai có thể cung cấp lý do cho việc không chọn một tên biến dài trong khía cạnh hiệu suất?


2
Hãy làm rõ câu hỏi của bạn - biến này ở đâu và nó được viết bằng ngôn ngữ nào?
Luke Graham

15
Bạn không bao giờ nên, EVER chọn tên biến ngắn và phi logic nếu lý do của bạn là hiệu suất (nghi vấn). Mã nguồn là có cho người khác đọc nó, không phải để đáp ứng máy tính và tăng hiệu suất vi mô của họ.
Michael JV

tôi đang sử dụng PHP ..
Avinash

1
... Và bạn sở hữu xpertdeveloper.com?
Jim G.

3
Xin chào Avinash bạn có thể giải thích trong câu hỏi của bạn lý do của bạn để nghĩ rằng đây có thể là trường hợp?

Câu trả lời:


16

Không nó sẽ không như vậy. Nói chung, khi mã được biên dịch, các tên biến được thay thế bằng địa chỉ bộ nhớ mà chúng tham chiếu. Máy tính không biết gì về tên biến; họ chỉ muốn biết nơi lưu trữ giá trị.

Biến là biểu tượng, không có gì hơn. Họ thay thế các giá trị hex bằng tên để các lập trình viên dễ hiểu hơn những gì họ đang làm. Vì vậy, sẽ không có tăng hiệu suất bằng cách chọn tên biến ngắn hơn.

Điều đó nói rằng, bạn có thể nhận được các cải tiến rất nhỏ (và tôi đang nói về kính hiển vi) trong thời gian biên dịch và diễn giải đầu tiên của JIT, nhưng đó chỉ là do trình phân tích cú pháp mất ít chu kỳ CPU để đọc tên biến. Đây là chi phí một lần và không đáng kể về mặt thống kê khi lo lắng về hiệu suất.


11
Mặc dù câu trả lời của bạn là chính xác cho lập trình ứng dụng, OP đang đề cập đến Trang web và do đó, có khả năng anh ta đang sử dụng ngôn ngữ được dịch. Trong trường hợp như vậy, mã sẽ cần phải được đọc từ tệp, sau đó được giải thích. Trong trường hợp này, một tên biến dài hơn sẽ mất nhiều thời gian hơn để tải & phân tích. Tuy nhiên, hiệu suất đạt được sẽ không đáng kể và được bù đắp một cách ồ ạt bởi những rắc rối thêm cho người lập trình đọc và hiểu mã.
Gavin Coates

1
@Gavin Cũng đúng cho các ngôn ngữ được giải thích - "Phiên dịch đầu tiên của JIT". Hầu hết các ngôn ngữ được giải thích hiện đang biên dịch khi chúng thực thi thay vì thực thi theo dòng, AFAIK.
Michael K

1
Michael - để biên dịch, trước tiên tệp phải được đọc vào bộ nhớ. Quá trình này sẽ mất nhiều thời gian hơn tùy thuộc vào độ dài của tệp. Tên biến dài hơn = tập tin dài hơn.
Gavin Coates

16

bất kỳ ai có thể cung cấp lý do cho việc không chọn một tên biến dài trong khía cạnh hiệu suất?

Michael bao gồm câu trả lời (tức là Không) nhưng tên biến có ảnh hưởng đến hiệu suất lập trình viên . Nếu bạn mang đến một nhà phát triển mới hoặc một người không quen thuộc với mã, thì việc có các tên biến dài và / hoặc khó hiểu có thể gây mất tập trung và làm chậm quá trình hiểu.

Nói chung, bạn muốn sử dụng các tên biến mô tả ngắn, vì chúng dễ đọc hơn. Hãy tưởng tượng nếu bạn phải bỏ qua mã của mình trong 10 năm và sau đó hiểu lại mọi thứ. Bạn có muốn đọc "getInput" hoặc "getInputFromUserWhoInputsStringOrElseInformReaderOfError" không? (cường điệu tất nhiên: P)

Tuy nhiên, có những lúc, khi có một cái tên dài hơn một chút có thể có lợi. Ví dụ, getBaptInput () sẽ mô tả nhiều hơn getInput (). Bạn muốn đơn giản hóa đến một điểm nhưng quá đơn giản hóa cũng có thể có vấn đề.


6
để đọc tên dài sẽ tốt hơn, nếu bạn tìm thấy "getInputFromUserWhoInputsStringOrElseInformReaderOfError", bạn không cần phải đọc tài liệu về chức năng này, nếu bạn tìm thấy "getInput" bạn cần. Và sau 10 năm tài liệu sẽ bị sai, hoặc không đầy đủ, hoặc thiếu. getInputFromUserWhoInputsStringOrElseInformReaderOfError chắc chắn là lâu dài, nhưng để hiểu về cái gì dài thì tốt hơn (và tôi không quan tâm rằng phụ nữ nói rằng kích thước không quan trọng).
Dainius

Tôi không đồng ý trong trường hợp này. Tôi nghĩ chỉ bằng cách đọc mã, sẽ khá dễ hiểu những gì getInput () làm, đặc biệt là nếu nó in "đầu vào không hợp lệ" hoặc một cái gì đó ngay sau đó. Có những lúc chắc chắn một cái tên dài hơn có thể tốt hơn - Tôi sẽ chỉnh sửa nó trong!
BlackJack

Tất nhiên, nó phụ thuộc vào ngữ cảnh, nhưng theo kinh nghiệm của tôi, tên dài hơn sẽ tốt hơn (nhưng không lâu bằng getInputFromUserWhoInputsStringOrElseInformReaderOfError). Và bối cảnh thực sự quan trọng như file.read () nhanh hơn file.read ALLFileAsByteArray (). Nhưng như tôi đã nói, IMHO tên dài hơn cung cấp nhiều thông tin hơn.
Dainius

1
Nếu tài liệu sai, không đầy đủ hoặc thiếu, thì cơ sở mã sẽ bị tiêu diệt.
Christopher Mahan

2
Đây là trả lời một câu hỏi không được hỏi.

7

Trừ khi bạn đang sử dụng bộ đệm op-code (còn được gọi là "trình tăng tốc PHP"), thì thực sự có một tác động. Nhưng tác động đó quá thấp, đến nỗi nó có thể bị bỏ qua. Nếu bạn sử dụng bộ đệm op-code, thì không có tác động.


1
và nếu bạn quan tâm đến hiệu suất đến mức bạn xem xét rút ngắn tên biến để đạt được một vài chu kỳ, thì việc không sử dụng bộ đệm op-code sẽ là tội phạm ... và nên chuyển sang ngôn ngữ được biên dịch như C sẽ được khuyến nghị.
SF.

Nhưng rõ ràng tác động đó là tích lũy, vì vậy ứng dụng càng lớn, tác động càng lớn, phải không?
n00dles

3

Mặc dù Michael là chính xác cho lập trình ứng dụng, câu hỏi của bạn đề cập đến phát triển web với PHP, đây là một ngôn ngữ được diễn giải. Trong trường hợp như vậy, mã sẽ cần phải được đọc từ tệp, sau đó được giải thích. Trong trường hợp này, một tên biến dài hơn sẽ mất nhiều thời gian hơn để tải & phân tích.

Tuy nhiên, hiệu suất đạt được khi làm như vậy sẽ không đáng kể và có thể sẽ nằm trong vùng phân số của một phần nghìn giây cho toàn bộ tập lệnh. Bạn luôn có thể dùng thử với một tập lệnh mẫu và sử dụng một phương thức thời gian như chi tiết tại http://www.developerfusion.com/code/2058/determine-execut-time-in-php/ nhưng điều này có thể sẽ không bắt đầu thời gian cho đến khi tập tin đã được đọc. Ngoài ra, thời gian thực hiện giữa các lần thử lại sẽ khác nhau nhiều hơn so với sự khác biệt giữa độ dài tên biến, do đó bạn sẽ cần phải thực hiện một số lần thử lại đáng kể và lấy trung bình mỗi lần thử trước khi bạn có thể có được một trung bình có ý nghĩa từ xa.

Như BlackJack chỉ ra, những cái tên dài hơn có thể khó hiểu hơn nhiều và phải nỗ lực rất nhiều để loại ra (và dễ bị đánh máy hơn nhiều). Mặc dù có thể có một hiệu suất tăng nhỏ, nhưng điều này không biện minh cho những rắc rối thêm được tạo ra cho lập trình viên. Như vậy, tên biến ngắn gọn, súc tích và dễ hiểu được ưa thích.

Vì vậy, trong ngắn hạn, đừng lo lắng về tên độ dài thay đổi, mà thay vào đó tập trung vào viết mã sạch, có ý nghĩa.


1

Có thể :

Mã máy chủ thường được biên dịch và độ dài tên biến sẽ không ảnh hưởng đến nó vì những lý do được đề cập. Tuy nhiên, nếu tên biến được sử dụng để xây dựng các hoạt động chuỗi đánh dấu khác nhau. Kể từ khi đáp ứng HTTP (có chứa đánh dấu / trở json / dữ liệu trả về) là lớn hơn, nó sẽ mất hơi lâu hơn, mặc dù sự khác biệt sẽ là không đáng kể. Nếu JavaScript không được thu nhỏ, nó sẽ là một tệp lớn hơn, mất nhiều thời gian hơn để di chuyển đến máy khách.

Khác với việc thu nhỏ các tệp JavaScript, mọi nỗ lực tối ưu hóa cho ứng dụng web / trang web, sẽ được chi tiêu tốt hơn cho các khía cạnh khác.


1

Vâng, nó sẽ, nhưng không phải trong ý nghĩa mà bạn đang nghĩ về.

Với tên biến xấu, nhà phát triển sẽ dễ bị nhầm lẫn trong mã nguồn. Nó sẽ khó đọc và khó hiểu.

Cuối cùng, mã nguồn sẽ khó duy trì và gần như không thể làm cho nó phát triển. Điều này chắc chắn sẽ dẫn đến chi phí bảo trì cao hơn, chi phí phát triển cao hơn, nhiều lỗi hơn và hiệu suất kém hơn .

Tên biến sẽ hoàn toàn không có ảnh hưởng trong thời gian chạy và hoàn toàn không đáng kể tại thời gian biên dịch. Nhưng tên xấu chắc chắn sẽ dẫn đến hiệu suất kém bởi vì không ai hiểu được mã và nó kết thúc trong một đống hack chồng lên nhau, khiến mọi thứ trở nên tồi tệ hơn mỗi lần.

Đọc những điều này để biết về tên biến tốt: http://tottinge.blossome.com/meaningfulnames

Lưu ý rằng nếu bạn cảm thấy sự cần thiết của tên biến rất dài, điều đó có nghĩa là mã của bạn được kiến ​​trúc kém. Một tên biến luôn bày tỏ trong một bối cảnh: namespace, tên lớp, tên tập tin, thư mục, tên hàm, vv Vì vậy, nếu cần tên là dài để được rõ ràng, phương tiện này rằng điều mà bạn đang cố gắng đặt tên doesn' T BÊN Ở ĐÂY . Trong trường hợp này, hãy suy nghĩ về việc đặt mã này vào vị trí thích hợp hoặc tạo địa điểm đó nếu nó chưa tồn tại.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.