Коли краще оптимізувати програмне забезпечення для кращої продуктивності на початку або в кінці розробки?


19

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

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


7
Продуманий експеримент: ви вибираєте інтерпретовану мову програмування для розробки інтерактивної гри, і ви виявляєте на півдорозі процесу розробки, що обрана вами мова не володіє необхідною швидкістю для задоволення вашої потреби в частоті кадрів. Ти по-царськи накручений?
Роберт Харві

8
Інший продуманий експеримент: ви ретельно оптимізуєте якийсь код у своїй грі, який, на вашу думку, є критичним для продуктивності, але потім запускаєте профайлер коду і виявляєте, що оптимізований код насправді не сприяє загальній продуктивності, і ви зменшилася чіткість коду. Ви витрачали свій час?
Роберт Харві

8
Висновок: чи це / чи рішення, чи може бути важливим прийняти деякі рішення щодо ефективності на початку, відклавши інші?
Роберт Харві

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

Як би ви не дивилися на це. На початку нічого оптимізувати не можна, оскільки з чим порівняти. Вам все одно потрібні 2 посилання, щоб щось оптимізувати: ідеальну продуктивність (відповідно до вимог) та реальну (ту, яку ви отримуєте, коли ви щось запускаєте).
Лаїв

Відповіді:


52

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

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

Тільки дві речі виводять мене з цього режиму:

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

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


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

12
@ PieterB: надзвичайно легко уповільнити розвиток за допомогою такої стратегії, як "помилки та поганий дизайн можна виправити пізніше" . Зауважте, що під поганим дизайном я маю на увазі такі речі, як нечитабельний, скручений код, а також перенастроенний код.
Док Браун

5
@Walfrat: Я думаю, що ваш приклад можна легко прискорити, не пошкоджуючи читабельності, і я інтерпретую цю відповідь не як "читабельний код не має жодних проблем із продуктивністю", а більше на кшталт "Проблеми з перфомансом автоматично не уникнути, зробивши код нечитабельна ".
Док Браун

2
@ PieterB: або у вас є клієнт, який хоче повернути свої гроші, оскільки товар, який вони придбали, настільки глючний, що не може ним користуватися.
Док Браун

2
@svidgen оцінювати швидкість нечитабельного коду без тестів поряд з неможливим. Зосередженість на швидкості та ігнорування читабельності створює незаперечні проблеми зі швидкістю. Зосередженість на читанні робить проблеми зі швидкістю настільки очевидними, що вам не доведеться думати про це. Ви побачите це, як тільки напишите. Навіть якщо ви цього не зробите, як тільки ви протестуєте його, ви зможете знайти проблему. Зважаючи на все це, чому хтось за замовчуванням повинен зосереджуватися на швидкості, ніж читабельності? Зосередженість на швидкості та ігнорування читабельності не дає жодного з них.
candied_orange

27

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

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

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

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


15

коли найкращий час для оптимізації програмного забезпечення для кращої продуктивності (швидкості).

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

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

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

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

Якщо припустити, що програмне забезпечення не надзвичайно велике і складне в управлінні

Це жахливе припущення.

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

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

Ви сидите там на порожній сторінці і пишете: void main() {}Почнете оптимізувати? Не можна нічого оптимізувати! Правильний порядок:

  • Зробіть це компіляцією
  • Зробіть це правильно
  • Зробіть його елегантним
  • Зробіть це швидко

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

Але там пропав крок. Реальне право замовлення:

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

"Продуктивність - це те, що користувач вважає продуктивністю." - Дійсно, колись користувальницька робота насправді краща, коли речі, на які ми очікуємо, потребують часу , потребують часу: webdesignerdepot.com/2017/09/when-slower-ux-is-better-ux
svidgen

можливо, "будьте науковими", а не "використовуйте науку" :)
синій

@svidgen: Я пам'ятаю, як одного разу змінив код, щоб уповільнити панель прогресу. У користувачів склалося враження, що якась реальна робота робиться, і були задоволені цим. Обчислювана функція була корисною, але, схоже, програма нічого не робила, якщо результат був після десятої секунди.
Джорджіо

2
@Giorgio: Це зустрічається зі мною, але я пам’ятаю, коли я вперше отримав жорсткий диск, і я врятував би гру чи документ і вважаю, що щось пішло не так, оскільки операція не зайняла часу, порівняно із збереженням на дискеті. І звичайно, зараз ігровий стан та документи настільки великі, що ми повертаємося до економії часу.
Ерік Ліпперт

3

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

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

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

User user = getUser();
int totalAmount;
for (Order o : user.getOrders()) {
  totalAmount += o.getTotalAmount();
} 

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

Кількість запитів SQL тут може вас здивувати. Звичайно, це залежить від структури ваших структур.

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


3

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

Очевидно, що ви не можете перевірити наявність вузьких місць, якщо всі компоненти вашої системи ще не вбудовані, тому ви не можете реально перевірити дуже добре на початку. З іншого боку, після побудови системи вам може бути не так легко вносити необхідні зміни, щоб отримати бажану продуктивність. Отже, це кістка-фіде Catch-22 .

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

Так, що ти робиш? Ну, кілька речей.

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

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

  3. Не переоптимізуйте рано. Ви ніколи не знаєте, що буде важливим, а що не має значення; алгоритм синтаксичного аналізу строків може не допомогти, наприклад, якщо ваша програма постійно чекає вводу / виводу.

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

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

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


1

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

Зрозумійте, що існує 2 дуже різних крайнощів.

Перша крайність - це речі, які впливають на значну частину дизайну, як, наприклад, як розділити роботу на скільки процесів та / або потоків і як частини спілкуються (сокети TCP / IP? Прямі дзвінки функції?), Чи реалізувати розширений JIT або інтерпретатор "одного коду за часом", або планувати структури даних, які підлягатимуть SIMD, або ... Ці речі, як правило, мають сильний вплив на реалізацію і після цього стають надмірно складними / дорогими для ретропристосування.

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

Між цими крайнощами - величезна сіра зона.

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

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


1

Найпростіше написати код, який не є ні інформаційним, ні ремонтопридатним. Складніше написати порформантний код. Складно ще написати письмовий код. І це найскладніше написати код, який є як технічним, так і ефективним.

Але, легше зробити ремонтопридатним кодом виконавця, ніж зробити код виконавця ремонтом.

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

Однак, враховуючи стан сучасного обладнання, у більшості систем не потрібно приділяти особливу увагу оптимізації з самого початку, а, скоріше, уникати знищення продуктивності, як правило, достатньо. Що я маю на увазі під цим, уникайте робити дурних справ, таких як повернення всіх записів таблиці, щоб отримати підрахунок, а не просто запитувати select count(*) from table. Просто уникайте помилок і докладайте зусиль, щоб зрозуміти інструменти, якими ви користуєтесь.

Далі спочатку зосередьтеся на тому, щоб зробити свій код постійним. Під цим я маю на увазі:

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

Отриманий код набагато простіше оптимізувати, коли статистика показує, що це потрібно.

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

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

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


1

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

Своєрідні випадки

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

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

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

Як можна пізніше

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

Дизайн, які пропонують дихальну кімнату оптимізувати пізніше

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

Зокрема, на моєму улюбленому сайті та аплеті було багато недоліків (будь-який нетривіальний розмір пензля сповільнився б до повзання), але він мав дуже приємне співтовариство. Щоб вирішити проблеми з продуктивністю, я використовував маленькі кисті з 1 або 2 пікселями і просто накреслив свою роботу так:

введіть тут опис зображення

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

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

Я думаю, що це порушення "здорового глузду", але, очевидно, це було не таким здоровим глуздом для розробника. Але все одно, що не абстрагувати речі на такому детальному рівні, коли мільйони, навіть пікселі чи частинки, або крихітні одиниці в симуляції великої армії, будуть відомі навіть самі основні випадки використання. Вподобайте IImage(ви можете обробляти всі формати зображень / пікселів, які вам потрібні на цьому об'ємному рівні сукупності) або IParticleSystemдо IPixelабо IParticle, і тоді ви можете вводити найпростіші та швидкі для запису та прості для розуміння реалізації такі інтерфейси та мати всю дихальну кімнату, яку вам коли-небудь знадобиться оптимізувати пізніше, не переглядаючи дизайн всього програмного забезпечення.

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

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


0

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

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

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


0

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

Продуктивність - це також простота використання. Деякі користувачі вважають за краще 1 натискання клавіші виконати завдання за 10 секунд, ніж 2 натискання клавіш виконати завдання за 1 секунду. Такі речі запитайте у дизайнера. Мені не подобається рано вживати подібні речі користувачам. У вакуумі вони можуть сказати X, але коли вони працюють з функціональним попереднім випуском, вони можуть сказати Y.

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

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

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

Ви впевнені, що вам потрібно зберігати предмети в колекції? Поширена проблема - це прочитати всі рядки з файлу до списку, а потім обробити список по одному рядку. Набагато ефективніше читати файл по одному рядку і пропускати список.

Ви тричі циклічаєте, коли один раз можете зробити цикл і зробити три речі.

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

Багато продуктивності також чистий код.

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.