ну я сейчас не могу посмотреть, но на некоторые особо популярные страницы, паук может ходить. правда что толку - поиск, как несложно видеть, все равно не работает.
пунто переквалифицировался :-)
доходы поисковика идут с рекламных объявлений. и если пользователю по профильному запросу выскакивают "профильные сайты", то ему по большому счету по барабану насколько то или иной сайт профильнее другого. а вот когда, по запросу порно выскакивают фирмы, торгующие дверями, тогда это его начинает по настоящему заботить. а таких умельцев как раз достаточно просто отслеживать и наказывать :-)
вот у меня, кстати, со спамом порядка 30-50 писем в день (и еще значительная часть спама отшибается не доходя до ящика). спама из них 90-99%. и ничего по поводу ошибок см. пост выше.
Фильтры бывают плохие и хорошие. Вот, кстати, яндексовый фильтр. Это не пиар, но действительно иногда ошибается, по наблюдениям за моим довольно активным ящиком за 5 лет, одна промиле проскакивает спам, десятая промиле в спам отправляется нужное письмо. Мейлрушный же ящик, например, регулярно пропускает половину спама.
Другое дело, что бороться с веб спамом несколько (если не на порядок) сложнее, но у меня есть большое подозрение, что пока еще никто серьезно не пытался этим заниматься. Нет такого стимула как с почтой. Все-таки как ни крути спамовая страница личное пространство не засоряет, а натыкаешься на нее только, когда ищешь.
Главная проблема, научиться зарабатывать на поиске деньги. То бишь найти инвестора, хорошего программера и маркетинговый план. Это же не шутка подвинуть таких столпов, как Янедкс, Гугль, Яху и Рамблер, которые в поиск уже немерянные тучи бабла вбухали. И, которые, на текущий момент являются раскрученными брендами. Сейчас, имея даже очень хорошие алгоритмы ранжирования, трудно будет убедить пользователя пользоваться новой поисковкой.
Со спамом бороться, кстати, довольно легко. Просто борьба с поисковым спамом еще не приняла такие масштабы, как борьба с мейловыми спамерами. Стимул не тот. Но как только, так сразу: будет ИМХО спец программа под названием вебоспамоборона и будет она с помосчью евристик чикать спамовые странички, или сильно понижать их релевантность :-)
Собственно речь шла больше про самописные vs стандартные, посему сразу хочу напомнить про один самописный класс, который был медленнее GNU и STLPort. 😂 😂 А еще про некий частичносамописный класс hash_map, который быстрее стандартного в два раза (а на самом деле не быстрее).
А теперь по поводу сравнения более быстрых готовых:
Илья, я знаю, что ты ничего не тестировал. И задачу такую, на которой GNU быстрее STLPort, придумать очень трудно, потому что
а) STLPort был до 2 раз быстрее в именно в однотредном режиме. В том числе на вполне реальных достаточно сложных приложениях, одно из которых: веб-сервер.
б) "Искусственные" тесты как раз тестировали основные операции работы со строкой: вставку, удаление, увеличение размера, поиск. Единственная обнаруженная операция, которая работает быстрее - создание пустой строки (на 10-20%), но она не очень частая. Поэтому единственный способ написать такой тест, про который ты говоришь, создать миллиард пустых строк или написать что-то, что предполагает refcounting при реализации строки, например:
string getStr(int k = 0) { if (k<1000) return getStr(k+1); return string("test string"); };
не очень жизненно, согласись. Пустые строки редко создаются, а строки по значению передавать нужно только по необходимости: чтобы была копию, которую можно изменить, не трогая оригинал. Если ты обнаружишь еще какие-то операции, на которых гну быстрее, то милости просим продолжить эту дискуссию.
в) сейчас очень много мультитредных приложений, а в них разница еще больше. и чем больше процов в машине, тем больше заметна разница.
15*300 * 10^6 = 4.5 * 10^9 все-таки не 13 гигов или я что-то не понимаю? :-)
Ууупс... Вы путаетесь в показаниях, если максимальная длина слова 15, то размер данных ну уж никак не 13 гигов. Опять-таки, какая средня длина, порядка 10 я думаю?
Поясните, плз, что значит разные версии STL? Все-таки, я это отношу больше к реализациям. Вы, конечно, правы, что разные реализации не вполне совместимы. Но если не использовать STL, то нужно использовать какой-то его аналог. А аналоги, я сам лично видел, кривее медленнее и хуже адаптированы к разным платформам. Возьмите, например, STLPort. И будем Вам счастье, а лучше Вы все равно (в общем и целом по интегральной оценке) не напишите. В частности там одна из самых "быстрых" реализаций строки (для строк размером до 100-200Кб точно). По-крайней мере, она сильно быстрее GNU string под FreeBSD и Linux.