Предлагаю устроить небольшое соревнование на скорость.
Для чего это нужно?
C#-гуру смогут посоревноваться пиписькомерством, а новички смогут почерпнуть много нового для себя.
Цель:
Нужно написать наиболее быстрый парсер, который будет парсить ники с одного из форумов + его репутацию (подробности ниже).
Техническая часть:
Писать можно только на C# (.net 1.0-4.5).
Использовать сторонние библиотеки запрещено.
Можно использовать любые фишки и плюшки языка.
Ограничений на ОЗУ нет.
Приложение может быть как консольным, так и GUI`шным.
Тестирование:
Основные замеры и сравнения будут проводиться на моей машине. (хотя вы можете делать независимые экспертизы ) Win 7 32b ; 4 гб ОЗУ + Intel I7 3314 Мгц ; Установлены все фреймворки
Скорость интернета: speedtest показал 4.42 на получение и 0.67 на передачу.
Пинг до сайта, который нужно будет парсить: 178
Что вы должны предоставить:
Исходный код вашей программы.
Скомпилированный реализ программы.
Замер времени:
Если ваше приложение консольное, то запуск парсера должен осуществляться после команды start , и после окончания должны выводиться результаты замера в консоль.
Если ваше приложение GUI`шное то у вас на форме должна быть кнопка start для запуска, результаты замера можете вывести например в MessageBox/
Замер времени производить с помощью класса System.Diagnostics.Stopwatch
1) Чтобы получить ники участников форума, нужно сформировать GET запрос вида [Ссылки могут видеть только зарегистрированные пользователи. ]
где %index%- это номер участника форума
В ответ на этот запрос вам придёт ответ HTTP 301 (HttpStatusCode.MovedPermanently) , в заголовке Location которого будет ссылка на профиль участника с нашим индексом.
2)Чтобы спарсить его репутацию, нужно отправить запрос на страницу профиля участника (пришла выше) и вытащить значение репутации.
Пример [Ссылки могут видеть только зарегистрированные пользователи. ].
3)Записать в файл результаты сбора первых 1000 пользователей и показать результаты замера времени.
Если кто то решит принять участие, то отпишитесь.
Принимаю все жалобы и предложения и вообще оценку идеи.
________________
Для просмотра ссылок или изображений в подписях, у Вас должно быть не менее 10 сообщение(ий). Сейчас у Вас 0 сообщение(ий).
ИМХО - бред.
Узкое место тут - пинг, любое отклонение от константы в большую сторону сотрет все старания по написанию алгоритма. в итоге твой метод сможет определить лишь самый плохой вариант ( и то если он реально ужасен).
Узкое место тут - пинг, любое отклонение от константы в большую сторону сотрет все старания по написанию алгоритма. в итоге твой метод сможет определить лишь самый плохой вариант ( и то если он реально ужасен).
Бесспорно, пинг самое узкое место. Но вот я сейчас пропинговал сайт и пинг 180 (178 вчера), то есть пинг достаточно стабильный (ну в зависимости от нагрузки и т.д. я понимаю это) + можно сделать корректировку: допустим до начала парсинга и после измерить пинг и найти среднее, далее мы знаем что на сбора 1 пользователя у нас уходит по 2 запроса, то есть задержка на 1 пользователя у нас будет %ping%*2 => %ping%*2*1000 - задержка на все операции, ну и вобщем мы можем найти более менее чистое время всего алгоритма.
Но цель соревнования показать друг другу "фишки и уловки" для повышения скорости выполнения операций. К примеру, если мы будем использовать Gzip сжатие запросов, будем использовать вместо регулярок обычный IndexOf, вместо for использовать foreach, вместо обычного string использовать stringBuilde и т.д. и т.п. то мы можем в бОльшей степени сократить время парсера.
________________
Для просмотра ссылок или изображений в подписях, у Вас должно быть не менее 10 сообщение(ий). Сейчас у Вас 0 сообщение(ий).
Бесспорно, пинг самое узкое место. Но вот я сейчас пропинговал сайт и пинг 180 (178 вчера), то есть пинг достаточно стабильный (ну в зависимости от нагрузки и т.д. я понимаю это) + можно сделать корректировку: допустим до начала парсинга и после измерить пинг и найти среднее, далее мы знаем что на сбора 1 пользователя у нас уходит по 2 запроса, то есть задержка на 1 пользователя у нас будет %ping%*2 => %ping%*2*1000 - задержка на все операции, ну и вобщем мы можем найти более менее чистое время всего алгоритма.
Но цель соревнования показать друг другу "фишки и уловки" для повышения скорости выполнения операций. К примеру, если мы будем использовать Gzip сжатие запросов, будем использовать вместо регулярок обычный IndexOf, вместо for использовать foreach, вместо обычного string использовать stringBuilde и т.д. и т.п. то мы можем в бОльшей степени сократить время парсера.
Я думал об этом, но нет, используя асинхронные запросы мы приходим к тому что процесс парсинга должен длится не дольше пинга, а с твоим процом, такое сделать очень просто...