Спецы ассемблера
#15 - смотри условия применимости.
Если вернуться к изначальному вопросу ТС, то питон и SQLite будет быстрее :) При этом как в кодинге, так и в работе. Зачем сортировать исходный файл все еще не понял :D
Индекс одноколоночной таблички - 100% дублирование оной.
Нет, индекс одноколоночной таблички избавляет от изменения порядка строк в исходнике. И больших объемах это важно.
Ээээ... каким образом?
Отсортированные данные выбираются простым SQL запросом.
Исходная задача говорит что - в сопоставлении с другими решениями - долго - нужно будет читать последовательно два списка, при этом один перечитывать сначала.
Про исходную задачу мы знаем ничего.
Решением в лоб - сортируем один список (загнав его в БД), дальше идем по элетентам 2-ого списка и ищем эти элементы в отсортированном. Все. Дальше уже надо смотреть на конкретный юз-кейс.
как в кодинге, так и в работе
-----
В кодинге - немного больше. См. sort /?
В работе - квадратично меньше.
избавляет от изменения порядка строк в исходнике
-----
За счет построения полного и упорядоченного дубля. У дубля как раз будет изменение порядка строк которого ты пытаешься избежать.
Все тоже самое получается физическим упорядочением исходного, но без избыточности на поддержание двух копий.
Отсортированные данные выбираются простым SQL запросом.
-----
Ну так Я и спрашиваю - каким образом при вставках неупорядоченных данных получается упорядоченный набор
Про исходную задачу мы знаем
-----
сортируем один список (загнав его в БД)
-----
Это никогда не имело место быть - добавление записей в базу никоим образом не упорядочивает записи...
Ну так Я и спрашиваю - каким образом при вставках неупорядоченных данных получается упорядоченный набор
Говорил уже - путем добавления к таблице индекса.
#8
Овет прост - да, решение с БД будет проще и выстрее, чем решение на ассемблере или любое другое самописное решение.
Это никогда не имело место быть - добавление записей в базу никоим образом не упорядочивает записи...
Само по себе добавление записи не упорядочивает, а если есть индекс, то 1) упорядоченный вывод становится в разы быстрее и 2) поиск по таблице (что и надо ТС) сокращается с 80млн до 8 сравнений.
путем добавления к таблице индекса
------
1. индекс не меняет положение записей в таблице
2. индекс одноколоночной таблицы содержит полную копию данных таблицы
3. индекс сортируется в указанном порядке
Т.е. ты 100% дублируешь количество данных и выполняешь сортировку всего объема данных.
Ну плюс еще оверхед по навигации через индекс - чтение индекса, затем чтение данных из таблицы.
Ну и количество чтений будет не единичным - не всегда данные будут на кешированной странице.
Если озаботишься прочтением и осознанием упомянутого ранее метода, то можешь осознать,
что вопрос решается за один проход - одно последовательное чтение, без возвратов, без крос-навигации...
проще и выстрее
-----
Проще - с точки зрения кодинга - да. примерно на 8-мь строк меньше.. ![]()
Насчет - быстрее - ой...
сокращается с 80млн до
8 сравнений
-----
8 сравнений на одно вхождение vs однократное линейное чтение всего массива...
и - да, можно поиграться с дополнительным акселерированием, но оно не даст большого выигрыша при строках переменной длинны...
Почитай про сортировку слиянием - модификация как раз даст нужный результат.
Это был самый полезный совет в этой теме, я чёта слишком сфокусировался на сравнении списков, а надо было слить всё в кучу и выцедить дубликаты,
решил через пару дней после прочтения и понятия сортировка слиянием, это же ежедневная работа любого администратора который работает с базами...
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.
