Чи важливо, щоб рішення було ефективним?

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

У реальному впровадженні - чи насправді важливо рішення проблеми ефективним? Якщо так, як я можу це покращити?

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

^^^ Це єдине, що потрібно насправді взяти з цієї відповіді. ^^^

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

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

Я погодився б з Майком Челліні, я б додав одне.

Це щось "досить ефективне"? Наприклад, з точки зору користувача, немає великої різниці між функцією, яка виконується за 0,00001 секунди, або тією, яка виконується за 0,1 секунди, хоча одна є набагато ефективнішою, ніж інша. Функція, яка виконується за 10 хвилин, не сильно відрізняється (для користувача) від функції, яка виконується за 12 хвилин. В обох випадках користувач отримав чашку кави або змістився з іншим завданням.

Я зрозумів, що ефективність є "ефективним користувачем", а не ефективним алгоритмом.

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

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

• Деякі студенти використовували простий цикл і формулу, що подається, щоб перевірити правильність чисел та відобразити їх, повільно, але виконали роботу, O (n ^ 3).
• Інші студенти зробили свої дослідження і знайшли формулу, яка зробила кращу роботу перевірки того, щоб задане число було дійсним, ці програми працювали набагато швидше, O (n ^ 2).
• Один учень використав повільну формулу для генерування значень, а потім скопіював їх у постійний масив у своєму коді та відобразив вміст цього, O (n).

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

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

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

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

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

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

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

Нарешті, курси інформатики стають все більш доступними в Інтернеті і охоплюватимуть фон, який потрібно вдосконалити.

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

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

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

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

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

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

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

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