Вывод. Скорее, Вашему вниманию предложен инструмент, помогающий в производстве выводов.
Выводы стоит делать для конкретной задачи, описанные данные намерено взяты достаточно понятными, исключительно для демонстрации. Хотя, разницу в часовых поясах из них можно вывести :)
Пожалуй, да. Поправил текст.
Меня ввела в заблуждение фраза "_CxxThrowException passes control to the operating system (through software interrupt, see function RaiseException) passing it both of its parameters" отсюда.
Ну что же делать, если «управление операционной системе уже давно не передается через программное прерывание». Кроме int 03, пожалуй, которая стоит особняком из за своей однобайтовости.
А передать хочется. Зачем — отдельный вопрос и не совсем ко мне. Видимо, для удобства отладки.
Конечно поверхностное, для полноценного вскрытия темы потребовалось бы написать «Войну и мира» или «Хождение по мукам», что было бы интересно только автору (ну и еще паре человек).
Что касается сравнения компиляторов, не очень понятно что именно сравнивать, вот есть такое сравнение, бессмысленное и беспощадное.
Исключения в нынешнем виде нельзя использовать для передачи управления, сравнивать как быстро программы восстанавливаются после сбоев?
Объем кода и pdata? Что именно Вам хочется сравнить?
_CxxThrowException передает управление операционной системе через программное прерывание. Это с одной стороны.
А с другой, в MS VC++(32) стек контекстов процедур реализован через общий с SEH регистр FS[0]. Какая-то путаница, видимо произошла.
Так и было описано в статье про SJLJ, разве нет? Для ARM он был как-то особо неудачно реализован, не зря в android ndk изначально исключения вообще не поддерживались, пока arm/dw2 был сыроват
Однако, если индекс не помещается в памяти, эти данные всё равно придется где-то хранить и лазить за ними на диск. Это справедливо для любой системы, не только СУБД. Речь может идти только о минимизации дисковых операций и Вы, видимо, считаете, что для индекса, написанного руками этого добиться проще. Я согласен, однако осмелюсь утверждать, что конкретная СУБД в целом для этих целей тоже подходит. Но дает еще приятный бонус в виде инфраструктуры.
Давайте считать :)
Пусть 40 млн документов.
Поиск по 4 словам.
Каждое поисковое слово встречается в 10% документов.
Всего надо прочитать 16 млн инвертированных записей. Записи эти для одного слова идут подряд и помежается их ну...500 на одну страницу субд.
Всего 32 000 страниц. Страницы все на диске и идут частично подряд и пусть на чтение уйдет в среднем 1 мс на страницу.
Итого, 32 секунды. Да, 2 минуты вполне достижимы :) но для очень тяжелого и маловероятного случая.
В памяти только словарь. Со всем остальным работа идет средствами sql процесссора.
А почему 250 * 80? Это же индекс. Такое может произойти только если все слова встречаются во всех документах. Что неверно в силу размера документа. Да и для таких случаев нечеткий поиск не очень то и нужен.
Выводы стоит делать для конкретной задачи, описанные данные намерено взяты достаточно понятными, исключительно для демонстрации. Хотя, разницу в часовых поясах из них можно вывести :)
Меня ввела в заблуждение фраза "_CxxThrowException passes control to the operating system (through software interrupt, see function RaiseException) passing it both of its parameters" отсюда.
А передать хочется. Зачем — отдельный вопрос и не совсем ко мне. Видимо, для удобства отладки.
Что касается сравнения компиляторов, не очень понятно что именно сравнивать, вот есть такое сравнение, бессмысленное и беспощадное.
Исключения в нынешнем виде нельзя использовать для передачи управления, сравнивать как быстро программы восстанавливаются после сбоев?
Объем кода и pdata? Что именно Вам хочется сравнить?
А с другой, в MS VC++(32) стек контекстов процедур реализован через общий с SEH регистр FS[0]. Какая-то путаница, видимо произошла.
Тут, например, этот флаг используется совместно с исключениями.
Пусть 40 млн документов.
Поиск по 4 словам.
Каждое поисковое слово встречается в 10% документов.
Всего надо прочитать 16 млн инвертированных записей. Записи эти для одного слова идут подряд и помежается их ну...500 на одну страницу субд.
Всего 32 000 страниц. Страницы все на диске и идут частично подряд и пусть на чтение уйдет в среднем 1 мс на страницу.
Итого, 32 секунды. Да, 2 минуты вполне достижимы :) но для очень тяжелого и маловероятного случая.
А почему 250 * 80? Это же индекс. Такое может произойти только если все слова встречаются во всех документах. Что неверно в силу размера документа. Да и для таких случаев нечеткий поиск не очень то и нужен.