Особливо, коли ви пишете "стандартні" (не для HPC) додатки, чи враховуєте ви, який алгоритм сортування вибрати, або просто розраховуватись з quicksort (що саме так називають більшість бібліотек сортування)? Певною мірою це може бути вигідним у конкретних ситуаціях, але з іншого боку, правильна оптимізація потребує певного часу для аналізу проблеми та визначення орієнтирів.
Відповіді:
Взагалі, використання методів за замовчуванням, якщо немає конкретної потреби робити щось більш екзотичне, зберігає все набагато більш читабельне / зрозуміле вниз по дорозі ІМХО.
Якщо ви відчуваєте (або в деяких випадках сильно підозрюєте), що у вас є проблеми з роботою, саме час додати складність.
З іншого боку, якщо ви використовуєте досить низьку мову, що немає вбудованого сортування для тих об'єктів, які вам потрібно сортувати, спробуйте вибрати один або два, які б охоплювали всі ваші бази та реалізували їх.
Завжди телефонуйте наданим процедурам бібліотеки, якщо у вас немає дуже-дуже вагомих причин цього не робити (і вам потрібно документувати, чому це так).
Це тому, що алгоритми сортування важко отримати абсолютно правильними. У Java Quicksort виникла помилка з дуже великими наборами даних, яку ідентифікували, виправляли та доставляли клієнтам Sun, тому вам цього не довелося.
Також сортування за замовчуванням у Java 7 було оновлено до нового, кращого сортування. Також безкоштовно.
Якщо сортування за замовчуванням не є доказовою не досить добре для вас, дотримуватися його.
На конференції одного разу я почув про це приємну історію.
У Microsoft хтось писав додаток VB (c. VB 3) і надсилав поштою групу людей, що казали, що у нього є величина значень, і він хотів, щоб вони з'явилися в комбінованій скриньці для того, як йому це робити.
Кожен занурився у свої старі підручники з інформатики, шукаючи високоефективні підпрограми та переносячи їх у Visual Basic та надсилаючи їх йому. Одні хлопці щойно відіслали повідомлення "скільки значень у комбобоксі?".
"Близько 50" прийшла відповідь.
Msgstr "Просто встановіть відсортовану властивість як TRUE".
У 99,9999% сортування найкраще проводити за допомогою бібліотеки, керування або вибору SQL, оскільки різниця в роботі між розпорядником бібліотеки та тим, що ви пишете, буде незначною, а зусилля та витрати на обслуговування значно перевищуватимуть наслідки.
Настав час витягнути класичну цитату про передчасну оптимізацію. У більшості випадків це насправді не має значення. Чорт, зі швидкістю процесорів в ці дні, ви могли б міхур сортувати більшість наборів даних і насправді не дуже помітити. Але коли ви сортуєте дійсно великі набори даних, а сортування продуктивності починає ставати проблемою, тоді вам неодмінно слід переглянути інші варіанти.
Хоча це, очевидно, не має значення для біт та часових позначок. Мені здається, що такий тип злиття простіше написати і зрозуміти, ніж швидкодіючий. Отже, якщо я збираюся написати власний алгоритм сортування, я би скористався цим.
Принаймні в грамотно написаній бібліотеці я б очікував, що вбудована версія sortбуде реалізована як Introsort, а не просто Quicksort. Різниця рідко має велике значення, але Introsort усуває найгірші показники роботи Quicksort з мінімальним впливом на більш поширені випадки.
Однак, щоб відповісти на ваше запитання: так - зазвичай з цього слід починати, і поки / доки у вас не з’являться результати профілера, що вказують на те, що це проблема, саме там вона повинна залишитися.