zvorygin

Принциипально существует два вида парсеров - DOM и SAX. Реализаций очень много что первых, что вторых. У обоих парсеров есть свои плюсы и минусы.

Тогда, можешь оставить настройки по-умолчанию - тебе должно будет хватить. А так - там есть вполне внятные описания каждой из настроек, а в интернете можно узнать подробности.

Так что если интересно узнать поглубже - то читай и копайся, если неинтересно - то непонятно зачем тебе gentoo )

Она же пишется в 5 строчек на яваскрипте...

Присутствие chrome dev tools, насколько мне известно, не определяется.

Не хватает метки mysql(ну или аналоги). Сортировка средствами БД обычно делается.

Например, напечатать символы возврата каретки и потом поверх напечатать новое сообщение.

printf('\b\bERROR');

@abdurahmanich, позволю себе не согласиться - поисковые машины, насколько мне известно, обращают внимание на селекторы вида "main", "content", "menu" и т.д. и пытаются применять эвристики для выбрасывания "ненужного". Так же они учитывают размер которым набран тот или иной текст для определения веса. Возможно, attr(title) они и не проиндексируют, но не могу давать 100% совет.

Можно попробовать поступить проще - на части страниц использовать attr(title) а на части страниц применять более классические варианты.

Chrome редко ошибается. Ты уверен, что ты не в Германии?

Chrome DevTools, вроде, умеют такое делать.

В "Алферовском Университете" (который на самом деле - Академический Университет), возможно скоро появится бакалавриат. Возможно только конкурс большой будет.

А кто вам сказал что там вообще есть ошибки? Нормальный лог запуска/остановки, мне кажется что ничего страшного тут не происходит.

Можно попробовать DLL Hooks.

Насколько мне известно, там все и так кешируется, и если между двумя запросами height не было модификаций DOM и CSS, то все отработает быстро.

Страуструп?

Тогда, если учесть, что запросы могут быть какими угодно, вам надо будет на каждый запрос читать всю таблицу хотя бы для того чтобы отфильтровать(хоть самописное у вас, хоть oracle, хоть mysql) - т.е. читать 5Гб (это самый медленный момент во всей системе). Если взять скорость последовательного чтения(а случайное чтени + SSD вам не помогут, как мне кажется), то время чтения будет порядка 5Гб/150МБс т.е. около 30 секунд. Если предположить что записи меняются редко, то можно все это дело дополнительно сжать(зависит от реальных данных) - хранить записи не фиксированной длины - возможно еще процентов 15(или больше) экономии выжмется - итого 25 секунд. Можно применить RAID и ускорить еще в пару раз(или в большее - в зависимости от реализации) - итого получаем 15 секунд на запрос. Никакие стандартные кеши при последовательном чтении не помогут, но можно попробовать просто забить всю свободную память кусками данных - и к ним обращаться не с диска - это дает еще 2Гб в памяти и, на вскидку экономию в 30-40 процентов. Итого, мне кажется, 10 секунд - довольно хороший гарантированный и достижимый результат на почти любых фильтрах и запросах. Если есть заранее известные данные о фильтрации, то можно пробовать как-то по-другому оптимизировать.

Тогда, мне кажется, самое простое, быстрое и правильное решение - написать свое приложение (или сервис, если так удобнее), которое будет хранить все эти данные в сыром файле и за один проход выдавать нужный список. Тогда можно будет выполнять такие запросы "относительно быстро" - меньше чем за одну минуту, причем в независимости от того, сколько одновременно запросов будет выполняться.

Причем выборка будет максимально честной. А вообще - можно взять на вооружение как интересную задачку для интервью)

Я в свое время использовал jsoup.org - парсер на яве, можно выдирать данные по css-селекторам - очень удобно оказалось.

Ну, как минимум надо позволять проставлять ссылки только на один определенный фотохостинг и только в одном формате, а то недоброжелатели могут всякого неприятного, в теории, попробовать сделать. Да и фотохостингу такой "хотлинкинг" не понравится - зачем ему лишняя нагрузка если он не может показать рекламу?