Невже повільне виконання мов програмування - це погано? [зачинено]

Ось як я це бачу.

Існує машинний код, і це все, що потрібно для комп'ютерів, щоб щось запустити. Комп'ютери не переймаються мовами програмування. Для них не має значення, чи походить машинний код від Perl, Python або PHP. Мови програмування не обслуговують комп'ютери. Вони обслуговують програмістів.

Деякі мови програмування працюють повільніше, ніж інші, але це не обов'язково, оскільки з ними щось не так. У багатьох випадках це тому, що вони роблять більше речей, що інакше мали би робити програмісти (тобто управління пам'яттю), і роблячи ці речі, вони краще в тому, що їм потрібно робити, - обслуговують програмістів.

Отже, чи погіршення продуктивності мов програмування насправді погана справа?

Я не думаю, що це автоматично погано. Python повільніше, ніж C ++, але коли обидва досить швидкі , Python може бути найкращим вибором для вирішення проблеми, навіть якщо це повільніше .

Це завжди компроміс. Для невеликих одноразових завдань набагато швидше написати скрипт Python, ніж додаток C ++, який робить те саме (типовим для мене прикладом може бути якась пакетна обробка тексту або перехід дерева дерев каталогів і щось робити з файлами), і мені не байдуже, чи потрібно це 10 мс або 1000 мс, навіть якщо це на 100 разів повільніше, тому що мені може знадобитися половина часу для написання та тестування.

Звичайно, було б добре, якби Python був таким же швидким, як C ++, тому в цьому сенсі я згоден з вашим твердженням, що "повільно = погано". Але тоді я маю потужну мову, яка працює так швидко, як я хочу, не виконуючи деякі речі (скажімо, перевірка меж масиву на необроблених масивах), поки це дозволяє мені вирішити, коли робити цей компроміс (скажімо, за допомогою std: : вектор).

Досить просто - бути повільним - це погано

коли програма вимагає певного рівня продуктивності

тому що без цього виконання ви не виконуєте вимог.

Це може бути все, що стосується бізнес-програми, яка потребує обробки запитів за прийнятну кількість часу, до гри, яка повинна відображати багато інформації на екрані в будь-який момент часу. Якщо програма недостатньо швидка, вона просто не працює .

Подивіться на це так: комп’ютери дурні . Вони завзято дотримуються вказівок, за якими може слідувати будь-який дебіл із триггерною таблицею. Вони вперто наполягають на тому, щоб робити те, що ви сказали, а не те, що ви мали на увазі. Не шматок самонавіювання чи інтуїції. Це жахливо.

Єдина річ, для якої працює комп'ютер, це швидко. Дійсно! Рукоятка з картотекою може зробити ту саму роботу, що і база даних. Якийсь хлопець, що викручує друкарський верстат, може робити те, що робить Apache. Серйозно! І вони РОЗУЧАЮТЬ на сотні і сотні років, по суті. Чому комп’ютер корисний для будь-якого, це його швидкість.

Таким чином, мова програмування, яка (порівняно з іншими мовами) не вдається використовувати, що не вистачає ТОЛЬКО переваги використання комп'ютерів.

Мова програмування може бути на дуже високому рівні, "робити багато", все ще бути дуже швидким. OCaml - мова вищого рівня, ніж PHP, але він виробляє код майже так само швидко, як і C. Javascript настільки ж динамічний, як PHP, але він може бути виконаний дуже швидко. Отже, це головним чином питання мовної реалізації, а не дизайн. Динамічні мови складніше реалізувати, але це неможливо.

Швидкість можна виміряти у термінах виконання, початкового часу розробки та часу технічного обслуговування (час, необхідний для переробки проблем / помилок та створення нового коду та розгортання).

Мови сценаріїв, як правило, мають більш повільний час роботи, але більш швидкий час обслуговування, тому що часто можна швидко змінити та розгорнути, не потребуючи відновлення цілої системи, а іноді навіть без зупинки та перезапуску.

Тому багато - це баланс залежно від потрібної вам швидкості.

Контекст також важливий. Завантаження початкової конфігурації займає 0,5 секунди замість 0,1 секунди - це не велика справа, але під час виконання, зайняття 0,5 секунди для виконання запиту замість 0,1 секунди може бути великою справою, якщо йому належить обробити 100 запитів, таким чином зайнявши 50 секунд замість 10.

Просто - клієнти люблять швидке програмне забезпечення. Насправді вся мета комп’ютерів полягає в швидкому обчисленні.

Повільне відносне. Якщо у мене є вимога читати порт 10 разів на секунду, мова, яка не може створити двійковий файл, може робити це занадто повільно. Якщо otoh, я пишу веб-додаток, де послідовність запитів / відповідей між сервером та браузером / клієнтом вимірюється в секундах, і користувач, швидше за все, витратить хвилини на екрані перед натисканням кнопки, мовою програмування, яка може обробляти обробку запиту. за 1 секунду, ймовірно, досить швидко (більшість, звичайно, набагато швидше).

Звичайно, мова програмування може бути фактором у визначенні швидкості виконання, але це буде не сама мова, а компілятори та / або умови виконання, які поставляються з нею. Це зрозуміло, бачачи розвиток Java, де продуктивність JVM (навіть в однакових апаратних середовищах) протягом багатьох років різко зросла. І звичайно, завжди можна писати жахливо повільний код у будь-якому середовищі, яке ви оберете. Оскільки такі твердження, як "C ++ в десять разів швидше, ніж Java", автоматично є неправдивими, якщо не кваліфіковано та не визначено, які саме умови були випробувані та як. Так само можливо створити тест, де Java швидше, ніж C ++, все залежить від того, що ви використовуєте в якості тестового коду та способу його виконання.

Оскільки мови програмування не існують для обслуговування програмістів, вони існують для створення програм для обслуговування користувачів.

Якщо вам просто потрібен простий маленький особистий інструмент, щоб зробити щось за один раз, це може бути так само повільно, як вам хочеться. Але як тільки ви починаєте розгортати користувачів, вони піклуються про швидкість і масштабування, особливо якщо вони збираються використовувати їх повторно. (Наприклад, інсталятор може бути повільним; програми, яку він встановлює, краще не бути.) І це не лише мова; це програма загалом. Якщо ваша програма повільна, користувачам це не сподобається. І якщо у вас конкуренція, користувачі, які не сподобалися вашій програмі, дуже погана річ. Тож мова, яка сприяє тим, що користувачі не подобаються вашій програмі (роблячи її повільною), погано.

Я є частиною команди, яка пише програмне забезпечення для контролю засобів масової інформації. Є хороший шанс, що ваша улюблена телевізійна або радіостанція працює на ній, якщо ви перебуваєте в США. Продуктивність - це одне, що ми найчастіше чуємо від клієнтів. Спочатку це було написано для невеликих операцій на одній станції, але зараз ми підписуємо великі трансляційні та кабельні мережі із сотнями каналів, і масштаб починає ставати проблемою. Якщо ми не зможемо змусити їх швидко працювати, вони візьмуть свої багатомільйонні контракти людям, які можуть, і ми закінчимося без роботи. Ось чому ми використовуємо швидку, компільовану мову та оптимізуємо хек з наших баз даних.

Бо швидше - краще. Час-гроші. Якщо ви пишете серверне програмне забезпечення та використовуєте більш повільну мову програмування, ви купуєте більше серверів. Якщо ви пишете скорочене програмне забезпечення, ви втрачаєте клієнтів у швидших конкурентів.

Для будь-якого довговічного програмного забезпечення, яке використовуються людьми, ми зазвичай хочемо його якомога швидше. На рівні зборів час на ринок збільшується занадто багато, щоб це не було вигідно. Це все компроміси. З точки зору бізнесу, може бути вигідніше дозволити бідним програмістам виправляти помилки пам'яті в C ++, роблячи це ще кілька місяців, якщо це означає, що продукт швидше, ніж ваші конкуренти.

Тому швидкість насправді важлива у багатьох програмних засобах. Повільні мови в даний час вважаються "поганими", оскільки вони справді занадто повільні (Python легко може бути 50x - 100x повільніше, і це занадто багато)

Мови програмування існують для обслуговування програмістів.

Я не знаю, як ви прийшли до цього висновку. Я б сказав: інженери програмного забезпечення використовують мови програмування для своїх потреб.

Деякі мови програмування повільніше, ніж інші, але це не тому, що з ними щось не так.

Це також неправдоподібне твердження. Визначте, що ви маєте на увазі, використовуючи тут слово 'повільніше'. Повільніше може означати:

1. Підсумкові програми, які досягають того ж, працюють «повільніше» однією мовою порівняно з іншою.
2. Час, необхідний для створення остаточної програми, може бути довшим (отже, деякі вважають це "повільнішим").

Ці два питання, які спадають на думку, також переплітаються там, де існує якийсь компроміс між часом, витраченим на розвиток та результативність.

Як і будь-яке програмне забезпечення, повільність може бути ознакою основних проблем / поганого дизайну. Проект, правда кажучи, є деяким zeitgeist, але це не погіршує цього факту, принципи дизайну, на яких він базується, застаріли і вважаються "поганими".

Візьмемо для прикладу класичні ASP та ASP.net.

Хтось прокоментував, що "Клієнти люблять програмне забезпечення, яке відповідає вимогам і в межах бюджету". Що ж, це правда - але це має відношення до повільного програмного забезпечення, і це, майже за визначенням, означає повільніші мови програмування (і рамки), алгоритми та конфігурацію. Повільна мова програмування, можливо, є найважливішою частиною всього вищезазначеного просто тому, що це основа, з якої вам буде найважче змінити. Якщо ви використовуєте DB Oracle і вам потрібно більше Perf, ви можете оптимізувати таблиці / індекс / тощо. Легко. Якщо у вашому коді поганий алгоритм, ви можете написати інший код. Якщо ваш фреймворк повільний, його можна замінити - це не так просто, але це можливо, не переписуючи все. Якщо ваша мова занадто повільна, вам доведеться практично починати заново.

Побачте, як у Facebook виникають клопоти, з якими вони змогли змусити PHP працювати досить швидко, коли потрібно масштабувати.

Для решти нас «нефункціональні вимоги до продуктивності» часто записуються в технічні характеристики, особливо для масштабованих веб-додатків. Якщо не виконати сторінку, 'повинна бути відображена користувачеві протягом 2 секунд після запиту ", і ви втрачаєте договір (або сплачуєте штрафні санкції). Так, так, клієнти люблять програмне забезпечення, яке виконує запити - і ці запитання скажуть, що це повинно бути швидким . (вас може не хвилювати, скільки часу користувачі проводять, дивлячись на пісочний годинник, але клієнт впевнений - це величезна вартість).

Наприклад, у великому кол-центрі мені сказали, що вони визначили, що за кожну секунду ви можете заощадити на процесі прийому дзвінків, 1 виклик може бути "зменшеним". Це раптом справжні гроші, і величезний стимул для начальників отримати швидше, ефективніше та більш корисне програмне забезпечення.

Багато часу витрачалося на занепокоєння, як програмісти максимально швидко відкручують код (а потім тестування та рефакторинг блоків весь час, хай). Я виявив, що це не стільки фактор, скільки люди вважають, що це - якщо ви знавець своєї мови, можете кодувати це набагато швидше, ніж якщо ви недосвідчені. Тож експерт C ++ Dev може писати код швидше і точніше, ніж початківець розробник PHP. Тому я вважаю, що стати експертом важливіше, ніж обирати "легку" мову, і саме тому мені не подобається культ "переписати в прохолодних, нових речах", які, здається, є скрізь сьогодні.

Я зазначу, що більшість проблем із продуктивністю існує тому, що програміст зробив погану роботу не тому, що мова була надто повільною. Дійсно, є багато важливіших речей, про які слід побоюватися у виконанні, ніж обрана вами мова. Це було б приблизно 1,203,407-го в моєму списку.

Отже, чи погіршення продуктивності мов програмування насправді погана справа?

За умови рівності, швидше - це добра річ. Зрештою, ніхто насправді не хоче більше чекати якихось результатів, і як тільки цей результат буде досягнутий, він може звільнити ресурси для інших речей.

Але не все інше рівне. Для початківців також важливо отримати правильний результат або хоча б достатньо правильний результат. (Якщо дозволені абсолютно неправильні результати, ви можете створити їх дуже швидко, і справді вони будуть мати рівно нульове значення для будь-кого.) Якщо зміна на дещо повільнішу мову робить більш ймовірним, що буде отримано правильний результат, зазвичай це великий компроміс. Мови вищого рівня мають перевагу перед мовами нижчого рівня, оскільки їхній багатший набір моделей, як правило, полегшує висловлення складної проблеми без надто багато чітких деталей.

Також зазвичай важливо керувати витратами на виробництво програмного забезпечення в першу чергу, додавати нові функції за бажанням та підтримувати його роботу в міру зміни базових систем. Мови вищого рівня зазвичай дозволяють прискорити поворот програмування, і це має велике значення у тому, щоб утримувати витрати на програмування в межах бюджету. Справді, зниження витрат там дозволяє досягти більше різних речей в цілому, що, як правило, є хорошою справою.

Останнім ключовим моментом, який слід зазначити, є те, що не потрібно використовувати лише одну мову і що у багатьох програмних системах більшість компонентів не є критичними. Використовувати мову низького рівня для створення високопродуктивних компонентів для критичних бітів є розумним, тоді як залишати менш критичні частини мові високого рівня (щоб мінімізувати витрати на їх виробництво) є надзвичайно розумним. Більше того, функції, які створюють хорошу мову низького рівня (здатність точно керувати тим, що працює машина), - це не ті функції, які створюють хорошу мову високого рівня (можливість виводити деталі з набагато менших описів): вони діаметрально протилежні, тому вміти з'єднати їх і використовувати їх для своїх сильних сторін та уникнути їх слабких сторін, це справді чудова річ.

Які компоненти повинні отримати високоефективну обробку? Оптимізація? Виміряйте їх. Профілюйте їх. Знайдіть правду, а не здогадуйтесь. Сфокусуйте свої зусилля там, де це найбільше користь.