Не, 500 са твърде много. В крайна сметка, всеки алгоритъм си има приложение, в зависимост от случая. Методът на мехурчето е подходящ, когато масивите са почти сортирани, и само някои елементи не са си на мястото. Тогава е и особено подходящо да се използва модификацията, в която веднъж се върви към края на масива, после към началото, после пак към края и т.н. Това е известно още като "сортиране с клатене".

За по-голям брой вече идват на помощ бързото сортиране на Хоор (още известно като QuickSort) и MergeSort, макар че последния има недостатъкът, че за сливането изисква малко повече памет (евентуално и процесорно време).

Ако пък обхватът на числата, които сортираш, е ограничен (например, имаш да сортираш 500000 числа, но всяко от тях има стойност от 1 до 50), най-подходящо е сортирането чрез броене - на един пас преброяваш всяко от тези числа колко пъти се среща, след което тръгваш по масива, в който помнищ бройките на числата, и записваш в оригиналния масив всяко число толкова пъти, колкото се среща. Както може лесно да се види, този алгоритъм има линейна сложност, но не е приложим винаги.

И въобще, алгоритмите за сортировка трябва да се познават, и да се избира най-подходящия за случая. Може да се ползва и комбинация от тях - например QuickSort, който обаче, когато останат под 10 елемента, започва с пряка селекция. Аз лично съм свидетел как Петър Митров, първенец по ученическите олимпиади по информатика преди години, за едно състезание си беше направил performance тестове - пряка селекция е по-бърза под еди колко си елемента, от толкова до толкова - този алгоритъм, от толкова до толкова - онзи алгоритъм, и използваше най-подходящия метод, в зависимост от броя на елементите, които му се налага да сортира. Естествено, неговата програма беше най-бързата