Коли "оптимізація коду" == "структурування даних"?

Недавня стаття ycombinator містить коментар із принципами чудового програміста.

#7. Хороший програміст: я оптимізую код. Кращий програміст: я структурую дані. Кращий програміст: в чому різниця?

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

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

Дизайнер знає, що досяг досконалості не тоді, коли не залишається нічого додати, а коли не залишається нічого, щоб забрати. - Антуан де Сент-Екзюпері

Добре структурована система буде мінімальною за своєю суттю, а завдяки мінімальному характеру вона буде оптимізована, оскільки те, наскільки мало її стосується, безпосередньо стосується того, наскільки мало вона робить для досягнення своєї мети.

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

Однак, існує цілком окрема можливість, що тут ухиляється, і це може бути те, що цей хлопець, який має стосунки з YCombinator, може посилатися на кодові дані AS в традиції гомоконічності LISP. Це тягнуться до думки про це як про значення в моєму розумі, але це YCombinator, тому я не виключаю, що цитата просто говорить, що LISPers - це "найкращий програміст".

Я думаю, автор натякає, що будь-яка перебудова даних призводить до реструктуризації коду. Тому реструктуризація даних з метою оптимізації вашої системи змусить вас оптимізувати і ваш код, підказуючи "в чому різниця?" відповідь.

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

Розглянемо найбільш очевидний приклад цього - "пошук даних користувачів занадто повільний!"

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

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

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

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

Є чудова книга (принаймні вона була в публікації) під назвою: Алгоритми + Структури даних = Програми .

Оптимізація коду може іноді покращити швидкість в два рази, а іноді і в десять, а то й двадцять, але це приблизно так. Це може здатися великим, і якщо 75% часу виконання програми витрачається на п'ятирядковій програмі, швидкість якої легко можна подвоїти, таку оптимізацію, можливо, варто зробити. З іншого боку, вибір структур даних може впливати на швидкість виконання на багато порядків. Сучасний гіпероптимізований багатопотоковий процесор, що працює над оптимізованим кодом для пошуку даних за ключем у лінійно пов'язаному списку на 10 000 000 елементів, що зберігається в оперативній пам'яті, буде повільніше, ніж набагато повільніший процесор, який працює з досить просто кодованою вкладеною хеш-таблицею. Дійсно, якби дані були викладені належним чином, навіть 1980-х "

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

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

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

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

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

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

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

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

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

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

Кращий програміст: в чому різниця?

Кращий програміст? Ні. Lousy програміст. Я припускаю, що слово "оптимізація" означає ті речі, які програмісти зазвичай намагаються оптимізувати, пам'ять або час процесора. У цьому сенсі оптимізація йде всупереч зерна майже всіх інших програмних показників. Розуміння, ремонтопридатність, доказовість та ін. Написання оптимального алгоритму швидкості / простору коштує значно більше з точки зору часу розробника, ніж наївне кодування алгоритму, представленого в якомусь тексті чи журналі. Пухнастий програміст не знає різниці. Хороший робить. Кращий програміст знає, як точно визначити, що потрібно оптимізувати, і робить це розумно.