response

response
Рейтинг
324
Регистрация
01.12.2004
Derek:
в дорах всегда есть хитрый замкнутый круг. что должно быть в софте и каков должен быть так сказать бизнес-процесс в условиях текущих реалий знает дорвейщик-практик. если он это знает и реализовал, то соответственно получает хороший профит и продавать софт за цену недельной окупаемоcти не будет (и даже за эту цену вряд ли кто купит, т.к. опять замкнутый круг - у школьников просто нет денег, у дорвейщиков-практиков есть свой софт). таким образом в случае продажи продукта остается один благоприятный вариант - создатель мог попаcть пальцем в небо и софт действительно является золотонесущей курицей. однако это пока никто не проверил (если бы создатель проверил, то не продавал бы по правилу замкнутого круга), так что покупателю предоставляется шанс за свои деньги проверить догадки создателя. это разумеется риск, разумный ли это риск решает каждый для себя сам.
ciber:
лично мне не интересно. если будет тема то я под нее софт быстро напишу. Сейчас темы нет, а значит ТС просто нужны бабки на НГ

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

UserCJ1:
Лучше жевать чем говорить (с)

ну так и в чем проблема-то?

Ярик:

Тема! - В идеале создание белого и постепенная (после индексации) подклейка черного с имитацией обновления - все на автомате, чтоб соблюдалось правило залил, скормил и забыл. ☝

эй, эта тема уже запатентована! 😂

entropy:
А с мелкими файлами случайно теста не видел?
Я видел один тест, правда в нем ntfs-3g, базирующийся вроде как на родном драйвере.
Так вот в том тесте ext3 делает ntfs, и немножко побыстрей UFS.
А так, по субъективной оценке простое копирование множества мелких файлов сравнить, и разница будет ощутимой.
Для больших файлов XFS рекомендуют, но ей требуется хорошая упса, при резете может слететь.

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

entropy:
response, да не требуется доргену никакой оптимизации. По крайней мере на данный момент скорость устраивает даже в винде. 8-10 секунд в винде на один дор вполне нормальный результат.
Получется 100 доров менее чем за 20 минут.
Регекспы, действительно медленнее работают. В доргене вынесены в отдельный блок кода. И также формирование некоторых структур данных вынесено. Поэтому в самом начале генерации некоторое время отнимает обработка текста.
Обработка данных при генерации дора занимает около двух секунд как в винде , так и в линуксе, запись на диск остальное время. В линуксе дор на 1600-1800 паг делается за 3 секунды, в винде за ~8 секунд. Вот и получается, что в винде узким местом оказываются файловые операции.

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

entropy:
Но в линуксе 8 лет работаю. Это уже давно моя основная система. Винда так, чтобы магаданы всякие запускать, ничего личного.

Всякие магаданы запускаются на юнихе, в чем проблема? 😂

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

А за вопрос этот я зацепился только потому, что упертый маздайщик :)

Вот, вроде посчиталось:

Это текущий рабочий кеш парсера. Понятно, что писалось все не за один раз, но при некоторых операциях промежуточного файла производится примерно столько же, и ниче, нтфске нормально. Как уже говорил, кое-где в топ жирности вылазят строчки по работе с не особо сложными/кривыми регэкспами (например на проектах, где каждый документ содержит много сущностей, например стата ливера с соткой кеев и сопутствующей кеям инфой на странице, или маркет, в котором из-за большого разнообразия разнотипных объектов, приходится каждый раз динамически выщемлять со странички поля характеристик, и т.д.)

Упертые виндусятники долбят винду и тюнят софт, а неупертые виндусятники сбегают в стан врага при первом же шухере.

Вот, пожалуйста:

Это скрин папки кеша нескольких проектов. Все это добро ворочается только в путь, на некоторых проектах под профайлером в топ по жирности вылезает работа с регэкспами, а лишь за ней идут операции чтения-записи. Да, пришлось повозиться, испробовать не один вариан организации работы с диском. Но в общем и целом при должном подходе нтфс вполне себе ничего вещь (глазами прикладного программиста, работающего с ней исключительно на уровне .net оберток, и выигрывающего за счет тюнинга архитектуры приложения).

Я почти уверен, что положи ваш дорген под профайлер, можно будет уже за первый вечер ускорить его раза в два-четыре. Попахивает предвзятостью, но судя по тому, как легко вы отметаете винду и выбираете линух (кстати, там уфс или что?), я склонен сделать вывод, что никакой оптимизацией в вашем продукте и не пахнет. Может я ошибаюсь, в любом случае, ничего личного. Хотите добиться истины - покажите код, а еще лучше - отчет профайлера ;)

зы

чуть позже выложу другой скрин, по всем проектам, лежащим в одной папке. Там статистика еще собирается :)

entropy:
Вот как раз на практике получается обратное.

да лана, нормальненько там все. на винде только фат страшилище, а нтфс вполне себе кошерная вещь. на линухе не загонялся оптимизацией, но на винде получаю вполне себе ничего скорости, к тому же, раз уж речь идет об оптимизации чтения-записи на винт, весь этот геммор в большинстве случаев не оправдан, потому что подкрутив систему на работу с рамдрайвом (ну, скажем, ворочая на нем сырые данные, и сохраняя результат на хдд), все фски сразу же идут лесом. Но перед этим необходимо еще убедиться, что софт уже достиг максимума, при котором все упирается именно в скорость чтения/записи. Это хорошая задача, которая, однако, вряд ли встанет всерьез перед каким-нить узкозаточенным парсером, вроед Магадана. Если проект тянет на полляма урлов и сотню лямов сущностей, то это уже серьезно, а дергая по ночам неспешно кеи, или генеря доры на марковке, пролезающие в мегабитный канал, прирост почувствуешь уже на обычном страйпе.

Короче, не забивайте людям голову 🍻

А Магадан пашет на линухе. Есть небольшие баги, но не критичные - все данные собираются и сохраняются корректно.

Lupus:
Уж здесь-то уберем.

уж уберите так уберите 😂

response добавил 17.12.2009 в 06:25

Dervish:
Но цитаты "хрен пойми кого" все же лучше и информативнее, чем метод Калинина с Лупусом, не находишь?

Лупус с Калининым тайными советниками были, но это секрет.

-= Serafim =-:
Вот кто-то базами и торгует.

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

Помните в своих спорах, что помимо коэффициента возврата, существует такое понятие как срок окупаемости.

Еще есть такая вещь, как диверсификация, но я боюсь поднимать эту тему, а то опять скатимся к обсуждению "доходности" различных видов бизнеса и не очень.

Всего: 3770