Взагалі кажучи, до якого типу оптимізацій ви зазвичай косуєтесь, розробляючи програмне забезпечення?

Ви тип, який вважає за краще оптимізувати ваш дизайн

• Час розробки (тобто швидкий запис та / або простіший в обслуговуванні)?
• Час обробки
• Простір для зберігання (або оперативної пам’яті, БД, диска тощо)

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

Технічне обслуговування

Потім, якщо потрібно, профілювання та оптимізація для швидкості. Рідко у мене коли-небудь виникала потреба в сховищі - принаймні, не за останні 10 років. До цього я це робив.

Час розробки

Обробка та зберігання - це дешево. Твого часу немає.

Просто зауважте:

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

У прямому порівнянні з часом обробки та зберігання я схиляюся до більш швидкого часу розробки. Чи використовуючи функцію віднімання collectionutils найшвидший і найефективніший метод пам'яті віднімання колекцій? Ні! Але це швидший час розробки. Якщо у вас виникли вузькі місця або продуктивність, ви можете їх вирішити пізніше. Оптимізація, перш ніж ви знаєте, що потрібно оптимізувати, - це марна трата вашого часу, і саме тому я виступаю проти.

Досвід користувача.

Це єдине значення, яке має значення для вашого замовника.

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

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

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

Естетика менш важлива. Я можу намалювати «Мона Лізу», але якщо вона схована за стіною, ніхто її не побачить.

Досвід користувачів - єдине значення, яке має значення. Зробити додаток, який робить саме те, що користувач хоче, так, як очікує користувач, - це остаточне досягнення.

Є лише одне, для чого слід оптимізувати, і це:

Чого хочуть ваші клієнти

Чи потрібні ваші клієнти якнайшвидшої програми? Оптимізуйте для швидкості.

Чи потрібні ваші клієнти абсолютної надійності? Оптимізуйте для цього.

Чи потрібна їм її завтра або вона буде марною? Оптимізуйте для швидкості розвитку.

Працює на неймовірно крихітному пристрої, обмеженому ресурсами? Оптимізуйте для цих ресурсів.

Час обробки

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

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

• Більшість кодів, що не викидаються, сильно паралельні. Це означає, що надмірне розподілення пам’яті та діяльність зі збору сміття будуть серіалізувати безліч інакше паралельних кодів. Це також означає, що для спільної шини пам'яті буде багато суперечок.
• Моя основна мова - D, яка ще не має хорошої 64-розрядної підтримки (хоча це вдається виправити).
• Я регулярно працюю з досить великими наборами даних.

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

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

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

Яку б технологію віртуалізації я не використовував

Пам’ятаєте дні, коли системи, що мають більше 512 Мбайт оперативної пам’яті, вважалися кров’ю, що кровоточить? Я провожу свої дні, пишучи код за попередніми.

Я працюю здебільшого над програмами низького рівня, які працюють у привілейованому домені в середовищі Xen. Наша стеля для пільгового домену становить 512 Мб, а решта оперативної пам’яті залишається безкоштовною для використання нашими клієнтами. Для нас також характерно обмеження привілейованого домену лише одним ядром процесора.

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

Точно, я оптимізую для:

• Слід пам'яті
• Сорти (де більша частина часу проводить мій код)

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

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

Це характерно і для тих, хто працює на вбудованих платформах, хоча навіть багато хто з них має принаймні 1 ГБ у своєму розпорядженні. Як зазначає Джейсон, це також характерно, коли записи програм запускаються на мобільних пристроях. Список продовжується, кіоски, тонкі клієнти, рамки для фотографій тощо.

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

Результати досліджень

Як академік, я подумав, що мені слід поділитися тим, для чого я оптимізований. Зауважте, що це не зовсім те саме, що оптимізація за коротший час розробки. Часто це означає, що робота може підтримувати якесь дослідницьке питання, але не бути достатнім, відшліфованим продуктом. Це може розглядатися як проблема якості, і це може пояснити, чому багато хто каже, що (академічні) комп'ютерні вчені не мають досвіду "реального світу". (Наприклад, "Хіба вони не знають, як інакше розробити товар, який можна отримати?" )

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

1. Дизайн
   • низька муфта, модульна
   • стислі, чітко визначені, функціональні області
   • добре задокументовані
   • безперервно рефактор для сировини
2. Обслуговування
   • відтворювана збірка та налагодження
   • одиничні тести
   • регресійні тести
   • контроль джерела

... після цього все інше

... нарешті, оптимізуйте для продуктивності ;-)

Якість / Тестування

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

Це залежить від потреби вашої програми.

Більшість того, що я роблю, є сильно обмеженим можливостями обробки та пам’яттю, але не зазнає дуже багатьох, якщо такі є, суттєвих змін у середньому році.

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

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

Елегантність .

Якщо ваш код добре розроблений, він матиме декілька ефектів:

1. Це буде простіше в обслуговуванні (скорочення витрат для замовника)
2. Це буде простіше оптимізувати (для JIT або повних компіляторів)
3. Це буде простіше замінити (коли ви думаєте про краще рішення)

Час розробки, абсолютно. Я також оптимізую пропускну здатність, але не переходжу до бінарного.

Оскільки я роблю установки на декількох типах систем, все, від мейнфрейму IBM до ПК, я спочатку оптимізую сумісність, потім розмір, а потім швидкість.

Це залежить

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

Однак у всіх випадках ваш код повинен працювати, і він повинен бути доступним.

Виразність мого наміру.

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

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

Усі

Час обробки

Сьогоднішні комп’ютери швидкі, але далеко не достатньо. Існує багато ситуацій, коли продуктивність є критичною - якщо ви використовуєте потокові медіа-сервери.

Зберігання

У вашого клієнта може бути великий диск, скажімо, 1Tb. Що можна зняти на 1000 відеофільмів високої чіткості, якщо ви хочете зробити його послугою, це далеко не достатньо, чи не так?

Час розробки

Ну, я не впевнений, чи вважаю це "оптимізацією", що я роблю, це те, що я використовую Java замість C ++, і розробка стає в 10 разів швидше. вперед і повністю скелі!

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