Là hiệu suất chậm hơn của ngôn ngữ lập trình, thực sự, là một điều xấu? [đóng cửa]

Đây là cách tôi nhìn thấy nó.

Có mã máy và đó là tất cả những gì máy tính cần để chạy thứ gì đó. Máy tính không quan tâm đến ngôn ngữ lập trình. Nó không quan trọng với họ cho dù mã máy đến từ Perl, Python hay PHP. Ngôn ngữ lập trình không phục vụ máy tính. Họ phục vụ lập trình viên.

Một số ngôn ngữ lập trình chạy chậm hơn các ngôn ngữ khác nhưng điều đó không nhất thiết vì có gì đó không ổn với chúng. Trong nhiều trường hợp, đó là vì họ làm nhiều việc hơn mà các lập trình viên sẽ phải làm (tức là quản lý bộ nhớ) và bằng cách thực hiện những việc này, họ sẽ làm tốt hơn những gì họ phải làm - phục vụ các lập trình viên.

Vì vậy, hiệu suất chậm hơn, của các ngôn ngữ lập trình, thực sự, là một điều xấu?

Tôi không nghĩ nó tự động xấu. Python chậm hơn C ++, nhưng khi cả hai đều đủ nhanh , Python có thể là lựa chọn tốt nhất cho vấn đề trong tay ngay cả khi nó chậm hơn .

Nó luôn luôn là một sự đánh đổi. Đối với các tác vụ một lần nhỏ, việc viết tập lệnh Python nhanh hơn nhiều so với ứng dụng C ++ cũng làm như vậy (ví dụ điển hình đối với tôi sẽ là một loại xử lý văn bản hàng loạt hoặc đi trên cây thư mục và làm gì đó với các tệp), và tôi không thực sự quan tâm liệu nó mất 10 ms hay 1000 ms, mặc dù nó chậm hơn 100 lần, bởi vì nó có thể khiến tôi mất một nửa thời gian để viết và kiểm tra.

Tất nhiên, sẽ rất tuyệt nếu Python nhanh như C ++, vì vậy theo nghĩa đó tôi đồng ý với tuyên bố của bạn rằng "chậm = xấu". Nhưng sau đó, tôi muốn có một ngôn ngữ mạnh mẽ chạy nhanh như tôi muốn bằng cách không thực hiện một số điều (giả sử, giới hạn mảng kiểm tra trên mảng thô) miễn là nó cho phép tôi quyết định khi nào thực hiện sự đánh đổi đó (giả sử, bằng cách sử dụng std: : vectơ).

Khá đơn giản - chậm là một điều xấu

khi chương trình yêu cầu một mức hiệu suất nhất định

bởi vì không có hiệu suất đó, bạn sẽ không đáp ứng yêu cầu.

Đây có thể là bất cứ thứ gì từ một ứng dụng kinh doanh cần xử lý các truy vấn trong một khoảng thời gian chấp nhận được cho đến một trò chơi cần hiển thị nhiều thông tin trên màn hình bất cứ lúc nào. Nếu chương trình không đủ nhanh, thì nó không hoạt động .

Nhìn nó theo cách này: máy tính thật ngu ngốc . Họ lập tức làm theo các hướng dẫn mà bất kỳ kẻ biến thái nào với bảng trig đều có thể làm theo. Họ cố chấp làm theo những gì bạn nói thay vì những gì bạn muốn nói. Không phải là một mảnh vỡ của tự định hướng hoặc trực giác. Thật kinh khủng.

Điều duy nhất mà một chiếc máy tính dành cho nó là nó rất nhanh. Có thật không! Một knucklehead với một tủ hồ sơ có thể làm công việc tương tự như một cơ sở dữ liệu. Một số anh chàng làm báo in có thể làm những gì Apache làm. Nghiêm túc! Và họ DID, trong hàng trăm và hàng trăm năm, như một vấn đề thực tế. Tại sao một máy tính tốt cho MỌI THỨ là tốc độ của nó.

Vì vậy, một ngôn ngữ lập trình (so với các ngôn ngữ khác) không khai thác được mà thiếu lợi thế CHỈ sử dụng máy tính.

Một ngôn ngữ lập trình có thể rất cao cấp, "làm rất nhiều", vẫn rất nhanh. OCaml là một ngôn ngữ cấp cao hơn PHP, nhưng nó đang tạo ra một mã gần như nhanh như C. Javascript cũng năng động như PHP, nhưng nó có thể được thực thi rất nhanh. Vì vậy, nó chủ yếu là một vấn đề với việc thực hiện ngôn ngữ, không phải là một thiết kế. Ngôn ngữ động khó thực hiện hiệu quả hơn, nhưng không phải là không thể.

Tốc độ có thể được đo lường về thời gian chạy, thời gian phát triển ban đầu và thời gian bảo trì (thời gian thực hiện để khắc phục các sự cố / lỗi và tạo mã mới và triển khai nó).

Các ngôn ngữ script thường có thời gian chạy chậm hơn nhưng thời gian bảo trì nhanh hơn vì bạn thường có thể thực hiện thay đổi và triển khai nhanh chóng mà không phải xây dựng lại toàn bộ hệ thống, và đôi khi không cần phải dừng và khởi động lại.

Do đó, rất nhiều là một sự cân bằng tùy thuộc vào tốc độ bạn yêu cầu.

Bối cảnh cũng quan trọng. Tải cấu hình ban đầu của bạn mất 0,5 giây thay vì 0,1 giây không phải là vấn đề lớn, nhưng khi chạy, mất 0,5 giây để thực hiện truy vấn thay vì 0,1 giây có thể là vấn đề lớn nếu phải xử lý 100 truy vấn, do đó mất 50 giây thay vì 10.

Đơn giản - khách hàng yêu thích phần mềm nhanh. Trong thực tế, toàn bộ mục đích của máy tính là tính toán nhanh chóng.

Chậm là tương đối. Nếu tôi có yêu cầu đọc một cổng 10 lần mỗi giây, một ngôn ngữ không thể tạo nhị phân có thể làm điều đó là quá chậm. Nếu tôi đang viết một ứng dụng web trong đó chuỗi yêu cầu / phản hồi giữa máy chủ và trình duyệt / máy khách được đo bằng giây và người dùng có thể dành vài phút trên màn hình trước khi nhấp vào nút, ngôn ngữ lập trình có thể xử lý yêu cầu xử lý trong 1 giây có lẽ là đủ nhanh (hầu hết tất nhiên là nhanh hơn nhiều).

Tất nhiên, ngôn ngữ lập trình có thể là một yếu tố quyết định tốc độ thực thi, nhưng đó sẽ không phải là ngôn ngữ mà là trình biên dịch và / hoặc thời gian chạy đi kèm với nó. Điều này rõ ràng khi thấy sự phát triển của Java, nơi hiệu năng của các JVM (ngay cả trên các môi trường phần cứng giống hệt nhau) trong những năm qua đã tăng lên một cách triệt để. Và tất nhiên, luôn luôn có thể viết mã chậm khủng khiếp trong bất kỳ môi trường nào bạn chọn. Vì các tuyên bố như "C ++ nhanh hơn mười lần so với Java" sẽ tự động không có thật trừ khi đủ điều kiện và định lượng chính xác các điều kiện đã được thử nghiệm và cách thức. Cũng có thể tạo ra một thử nghiệm trong đó Java nhanh hơn C ++, tất cả phụ thuộc vào những gì bạn đang sử dụng làm mã thử nghiệm và cách bạn thực hiện nó.

Vì ngôn ngữ lập trình không tồn tại để phục vụ lập trình viên, nên chúng tồn tại để tạo chương trình phục vụ người dùng.

Nếu bạn chỉ cần một công cụ cá nhân nhỏ đơn giản để làm một việc gì đó một lần, nó có thể chậm như bạn muốn. Nhưng một khi bạn bắt đầu triển khai cho người dùng, họ quan tâm đến tốc độ và tỷ lệ, đặc biệt là nếu họ sẽ sử dụng nó nhiều lần. (Ví dụ, trình cài đặt có thể chậm; chương trình mà nó cài đặt tốt hơn là không.) Và đó không chỉ là ngôn ngữ; đó là chương trình tổng thể. Nếu chương trình của bạn chậm, người dùng sẽ không thích nó. Và nếu bạn có sự cạnh tranh, người dùng không thích chương trình của bạn là một điều rất tồi tệ. Vì vậy, một ngôn ngữ đóng góp cho người dùng không thích chương trình của bạn (bằng cách làm cho nó chậm) là xấu.

Tôi là thành viên của một nhóm viết phần mềm điều khiển cho phương tiện truyền thông phát sóng. Có một cơ hội tốt TV hoặc đài phát thanh yêu thích của bạn đang chạy trên nó nếu bạn ở Hoa Kỳ. Hiệu suất là một trong những điều chúng tôi nghe thấy thường xuyên nhất từ ​​khách hàng. Ban đầu nó được viết cho các hoạt động của một trạm nhỏ, nhưng hiện tại chúng tôi đang ký các mạng truyền hình và truyền hình cáp lớn với hàng trăm kênh và quy mô bắt đầu trở thành một vấn đề. Nếu chúng ta không thể khiến mọi thứ chạy nhanh cho họ, họ sẽ mang những hợp đồng trị giá hàng triệu đô la của họ cho những người có thể, và chúng ta sẽ mất việc. Đó là lý do tại sao chúng tôi sử dụng ngôn ngữ được biên dịch nhanh và tối ưu hóa cơ sở dữ liệu của chúng tôi.

Bởi vì nhanh hơn là tốt hơn. Thời gian là tiền bạc. Nếu bạn viết phần mềm máy chủ và bạn sử dụng ngôn ngữ lập trình chậm hơn, bạn sẽ mua nhiều máy chủ hơn. Nếu bạn viết một phần mềm thu nhỏ, bạn sẽ mất khách hàng trước các đối thủ nhanh hơn.

Đối với bất kỳ loại phần mềm lâu dài nào được mọi người sử dụng, chúng tôi thường muốn nó nhanh nhất có thể. Ở cấp độ hội, thời gian tiếp thị tăng quá nhiều mà không mang lại lợi nhuận. Đó là tất cả sự đánh đổi. Từ góc độ kinh doanh, có thể có lợi hơn khi để các lập trình viên nghèo gỡ lỗi bộ nhớ trong C ++, làm điều đó trong vài tháng nữa, nếu điều đó có nghĩa là sản phẩm nhanh hơn đối thủ của bạn.

Vì vậy, tốc độ thực sự quan trọng trong nhiều phần mềm. Ngày nay, các ngôn ngữ chậm được coi là "xấu" vì chúng thực sự quá chậm (Python có thể dễ dàng chậm hơn 50 lần - 100 lần và quá nhiều)

Ngôn ngữ lập trình tồn tại để phục vụ lập trình viên.

Tôi không biết làm thế nào bạn đi đến kết luận này. Tôi muốn nói: các kỹ sư phần mềm sử dụng ngôn ngữ lập trình cho nhu cầu của họ.

Một số ngôn ngữ lập trình chậm hơn ngôn ngữ khác nhưng không phải vì có gì đó không ổn với chúng.

Đây cũng là một tuyên bố flakey. Xác định ý của bạn bằng cách sử dụng từ 'chậm hơn' ở đây. Chậm hơn có thể có nghĩa là:

1. Các chương trình cuối cùng, đạt được điều tương tự, chạy 'chậm hơn' trong một ngôn ngữ so với ngôn ngữ khác.
2. Thời gian để tạo chương trình cuối cùng có thể lâu hơn (do đó, một số người sẽ mô tả nó là 'chậm hơn').

Hai vấn đề nảy sinh trong đầu cũng đan xen trong đó có một sự đánh đổi nào đó giữa thời gian dành cho phát triển và hiệu suất.

Giống như bất kỳ phần mềm nào, việc chậm có thể là dấu hiệu của các vấn đề tiềm ẩn / thiết kế xấu. Thiết kế là một chút của một zeitgeist thừa nhận, nhưng điều này không làm mất đi thực tế đó các nguyên tắc thiết kế mà nó hiện đang dựa trên đã lỗi thời và được coi là 'xấu'.

Lấy Classic ASP và ASP.net làm ví dụ.

Có người nhận xét rằng "Khách hàng thích phần mềm thực hiện theo yêu cầu và trong ngân sách". Chà, điều này đúng - nhưng nó khá có liên quan đến phần mềm chậm, và điều đó, gần như theo định nghĩa có nghĩa là ngôn ngữ lập trình (và khung) chậm hơn và thuật toán, và cấu hình. Một ngôn ngữ lập trình chậm có thể là phần quan trọng nhất trong tất cả những điều trên chỉ đơn giản vì nó là nền tảng mà từ đó bạn sẽ thấy khó thay đổi nhất. Nếu bạn sử dụng Oracle DB và cần hoàn hảo hơn, bạn có thể tối ưu hóa các bảng / chỉ mục / v.v. Dễ dàng. Nếu bạn có một thuật toán kém trong mã của mình, bạn có thể viết các mã khác nhau. Nếu khung của bạn chậm, bạn có thể thay thế nó - điều đó không dễ dàng nhưng nó có thể thực hiện được mà không cần viết lại mọi thứ. Nếu ngôn ngữ của bạn quá chậm, thực tế bạn phải bắt đầu lại.

Xem Facebook về những rắc rối họ gặp phải để làm cho PHP hoạt động đủ nhanh khi họ cần mở rộng quy mô.

Đối với phần còn lại của chúng tôi, 'yêu cầu hiệu suất phi chức năng' thường được viết thành thông số kỹ thuật, đặc biệt là cho các ứng dụng web có thể mở rộng. Không hoàn thành trang 'phải được hiển thị cho người dùng trong vòng 2 giây kể từ khi yêu cầu "và bạn mất hợp đồng (hoặc phải trả tiền phạt). Vì vậy, có khách hàng yêu thích phần mềm thực hiện với reqs - và những yêu cầu đó sẽ nói rằng nó phải nhanh (bạn có thể không quan tâm người dùng dành bao nhiêu thời gian để nhìn chằm chằm vào đồng hồ cát, nhưng khách hàng chắc chắn làm được - đó là một chi phí rất lớn).

Ví dụ, tại một trung tâm cuộc gọi lớn, tôi được cho biết rằng họ đã xác định rằng cứ mỗi giây bạn có thể tiết kiệm được quy trình thực hiện cuộc gọi, 1 người gọi có thể bị 'thu hẹp'. Đó là tiền thật đột ngột, và một động lực rất lớn cho các ông chủ để có được phần mềm nhanh hơn, hiệu quả hơn và có thể sử dụng nhiều hơn.

Có rất nhiều thời gian để lo lắng về việc các lập trình viên tạo ra mã nhanh nhất có thể (và sau đó kiểm tra đơn vị và tái cấu trúc mọi lúc, lol). Tôi đã thấy rằng đây không phải là một yếu tố như mọi người nghĩ - nếu bạn là một chuyên gia về ngôn ngữ của bạn, bạn có thể viết mã nhanh hơn nhiều so với khi bạn không có kinh nghiệm. Vì vậy, một chuyên gia phát triển C ++ có thể viết mã nhanh hơn và chính xác hơn một nhà phát triển PHP mới làm quen. Vì vậy, tôi nghĩ việc trở thành một chuyên gia quan trọng hơn việc chọn một ngôn ngữ 'dễ dàng' và đây là lý do tại sao tôi không thích sự sùng bái 'viết lại trong những thứ hay ho, mới mẻ' dường như ở khắp mọi nơi ngày nay.

Tôi sẽ chỉ ra rằng hầu hết các vấn đề về hiệu năng tồn tại bởi vì lập trình viên đã làm một công việc tồi tệ không phải vì ngôn ngữ quá chậm. Thực sự, có nhiều điều thích hợp hơn để lo lắng về hiệu suất so với ngôn ngữ bạn chọn. Đó sẽ là con số xấp xỉ 1.203.407 trong danh sách của tôi.

Vì vậy, hiệu suất chậm hơn, của các ngôn ngữ lập trình, thực sự, là một điều xấu?

Mọi thứ khác đều bình đẳng, đi nhanh hơn là một điều tốt. Rốt cuộc, không ai thực sự muốn chờ đợi lâu hơn cho một số kết quả, và một khi kết quả đó được thực hiện, nó có thể giải phóng tài nguyên cho những thứ khác.

Nhưng không phải mọi thứ khác đều như nhau. Đối với người mới bắt đầu, điều quan trọng là tạo ra kết quả đúng , hoặc ít nhất là đủ đúng. (Nếu kết quả hoàn toàn sai được cho phép, bạn có thể tạo ra những kết quả rất nhanh và chúng sẽ có giá trị chính xác bằng 0 đối với bất kỳ ai.) Nếu thay đổi sang ngôn ngữ chậm hơn một chút sẽ khiến cho kết quả đúng sẽ được tạo ra, đó thường là một đánh đổi lớn Các ngôn ngữ cấp cao hơn có lợi thế hơn các ngôn ngữ cấp thấp hơn ở đây, vì bộ mô hình phong phú hơn của chúng thường giúp dễ dàng diễn đạt một vấn đề phức tạp mà không có quá nhiều chi tiết rõ ràng.

Điều quan trọng thường là quản lý chi phí sản xuất phần mềm ngay từ đầu, thêm các tính năng mới như mong muốn và giữ cho nó hoạt động khi các hệ thống cơ bản thay đổi. Các ngôn ngữ cấp cao hơn thường cho phép quay vòng lập trình nhanh hơn và có rất nhiều giá trị trong việc giữ chi phí lập trình trong ngân sách. Thật vậy, giữ chi phí ở đó cho phép đạt được nhiều thứ khác nhau hơn, nói chung là một điều tốt.

Điểm mấu chốt cuối cùng cần lưu ý là không cần thiết chỉ sử dụng một ngôn ngữ và nhiều hệ thống phần mềm có phần lớn các thành phần của chúng không hoạt động quan trọng. Sử dụng ngôn ngữ cấp thấp để tạo ra các thành phần hiệu suất cao cho các bit quan trọng là điều hợp lý, trong khi để các phần ít quan trọng hơn thành ngôn ngữ cấp cao (để giảm thiểu chi phí sản xuất chúng) là điều hợp lý. Hơn nữa, các tính năng tạo ra ngôn ngữ cấp thấp tốt (khả năng kiểm soát chính xác những gì máy làm) không phải là các tính năng tạo ra ngôn ngữ cấp cao tốt (khả năng suy luận chi tiết từ các mô tả nhỏ hơn nhiều): chúng trái ngược nhau về mặt đường kính, vì vậy việc có thể ghép chúng lại với nhau và sử dụng chúng cho những điểm mạnh của chúng và tránh những điểm yếu của chúng, đó thực sự là một điều tuyệt vời.

Những thành phần nào sẽ nhận được điều trị hiệu suất cao? Việc tối ưu hóa? Đo lường chúng. Hồ sơ họ. Tìm sự thật chứ không phải đoán. Tập trung nỗ lực của bạn, nơi nó làm tốt nhất.