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

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

Отредактировано slbgz (18-10-2011 17:47:13)

slbgz
> делить на фрагменты даже махонькие 100-килобайтные файлики и даже - еще более мелкие
У тебя Windows XP? В её духе. Кстати, а зачем я спрашиваю? У тебя именно Windows XP.
На сколько я помню даже виста научилась не делать такой параши, а Linux такой параши не делает уже очень давно.

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

Файлики находящиеся в памяти действительно быстрее работают, но между тем, как работает чтение-запись в базу данных и XML-структуру есть гигантская разница, которую ты осознавать не хочешь или просто не можешь. А если учесть, что в любом случае закладки поднимаются в память и вся работа ведётся в памяти, то не играет ни какой роли загрузил ли ты их в память до этого или нет (загрузка базы в фоксах выше 3го точно просиходит в фоне). Но! Второму фоксу нужно периодически выполнять запись полного дампа файла закладок, тогда как более новым версиям полный дамп делать не нужно. Ему нужно сформировать XML-структуру и записать её на винт. Причём он достаточно туп, чтоб не уметь делать этого в параллельном процессе, на сколько я его помню. Именно потому операции с этим файлом отнимают чудовищьно много времени. Именно потому ты получаешь ускорение при размещении этого недоразумения на виртуальном винте и именно потому это даёт куда меньший эффект в последующих версиях фокса. Вот дефрагментация таблиц в базе (не файла базы! он обычно мало фрагментирован) куда полезнее, но фокс, вроде, и сам уже научился это делать.

okkamas_knife
> кто вам это сказал?
Я немного изучал как работют файловые системы в линукс и на сколько я помню NTFS в винде работает подобным образом. Во всяком случае после XP. Как NTFS поступает с выделением места под файлы в самом XP я не помню.

> и кстати объясните почему именно 10мб а не 16 или  5 или не 100?
Почему именно 10 я понятия не имею. Может они взяли её с потолка, а может изучили отчёты, которые присылаются им теми, кто использует TestPilot и пришли к выводу, что это оптимальный размер блока.

> как вы думаете почему мс ушли с фата ?
Ты правда думаешь, что из-за размера чанка? Эта файловая система изначально была на столько плоха, что им было проще придумать новую, чем исправить старую. Одни только права доступа к файлам чего стоят. В FAT32 очень сильно отличается от NTFS и говорить, что MS отказались от FAT32 только из-за размера блоков просто не умно.

> зы и не забываем что флэшки в отличие от винтов имеею ограниченное число циклов записи-чтения
И большой размер файла позволяет базе дописывать новые данные в конец после последнего используемого блока, а не переписывать старые, что экономит тебе циклы чтения-записи.

> соответственно больше файл больший кусок будет подвергаться использованию.
Этот файл не переписывается целиком каждый раз, как это происходило во втором фоксе. Так что блоки будут просто отведены под этот файл, но в них ни чего не будет записано или 1 раз в них будут записаны нули. И всё, дальше они будут ждать когда они реально понадобятся.

> а также не забываем про антивирусы которые
Некоторые настраивают проверять абсолютно все файлы в системе и даже внутри архивов. Но мы же не такие? Правда?
Мы же не будем нагружать постоянно активный сканер непосильной ношей, а потом удивляться почему он сожрал всё процессорное время и у нас всё тормозит.
А проверка по требованию… На общем фоне разницы ты не заметишь если будешь проверять весь портативный фокс, а не конкретно этот файл, конечно же.

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

> ага-ага и с каких это пор синхронизация передаёт только кусочки файла?
Я говорю о механизме синхронизации встроенном в сам Firefox. Ты можешь поднять у себя сервер аналогичный ихнему серверу синхронизации. В отличие от Google Chrome, где для синхронизации можно использовать только Google.
Естественно если ты будешь использовать rsync или что-то вроде, то копировать будешь все новые файлы.

Отредактировано Lain_13 (18-10-2011 19:43:37)

slbgz
Наверное если запускать на очень-очень бюджетном железе вроде твоего, то да, даже база будет заметно уступать работе в памяти. Но это нужно на редкость бюджетное железо. Я запускал фокс со своим профилем на не дорогих ноутах и он там не тормозил и не подвисал.
Не дорогой читается как «приблизительно 3-5 тыс. грн.». Видимо ты нашёл нечто заметно более дешёвое и потому тебе пришлось так плясать. Тогда уже не играт большой роли второй у тебя фокс или 10й — на винт записи всё равно не происходит до последнего момента.

Я не говорю, что твое решение не верно. Оно действительно работает и многим помогло, но ты его продвигаешь как единственное верное, а это не так. Это единственное верное решение для очень плохого железа.

Отредактировано Lain_13 (18-10-2011 20:06:02)

okkamas_knife
> насчет фрагментации у маленького файла гораздо меньше шансов оказаться фрагментированным а если не забивать базу мусором то под хранение закладок нужно вобщемто не так уж и много места.
Если выделить кусок сразу, а не постепенно, то шансы оказаться фрагментированным у него гораздо ниже. Вот если постепенно, то запись может происходить куда угодно. Я там приводил пример выше — все качалки современные выделяют сначала место под файл, а потом его качают. Это значительно снижает фрагментирование даже для очень больших файлов и это реально работает.
А так при добавлении в базу очередной закладки базе нужно изменить размер файла и этот новый кусок может упасть буквально _куда угодно_. Хорошо, если там рядом было место, а если в другой конец диска?

> как я уже писал выше у мея 10 000(!) закладок занимают всего 7 мегов.  средний же пользователь елеле тыщу насобирает
> соответствено его база меньше мегабайта выйдет.
Фавиконки. Они, мать их, разные. Некоторые суют фавиконки размерами хоть до 512х512 (а точнее всю гамму от 16х16 до 512х512). Если такая оказывается в базе, то отжирает она соответственно.

> которые сделали бы размер кратным степени двойки.
Священная корова, да?
Ну сделали бы они выделение блоков по 8 или 16 Мб — тебе было бы от этого лучше?

> ты серьёз думаешь что фф обращается напрямую к диску и считывает -пишет только конкретные кластеры?
За это отвечает не фокс, а SQLite в него встроенный, который пишет и читает конкретные участки файла базы. Он не делит его на физические кластеры, но делит на удобные ему логические блоки. Он выполняет перезапись одного логического блока, ну а система уже переписывает соответствующие ему физические кластеры. Но не весь файл целиком.
Ты представляешь как скачивается торрент-файл, например? Запись ведь происходит не по порядку, а равномерно по всему файлу. Представляешь что происходило бы при закачке 1 Гб файла если бы запись каждого блока (а они могут быть от 512 байт размером, вроде, а может и ниже, я не помню и до нескольких мегабайт) вызывала бы перезапись всего файла? Торрент-клиент тоже делит файл на удобные ему логически блоки и пишет в них данные, а разместить их на винте забота системы. Причём он сначала просит выделить объем равный объёму скачиваемого файла, а не просит выделить чуть-чуть места под каждый блок по очереди (если, конечно, не выключить эту функцию).

Отредактировано Lain_13 (18-10-2011 20:30:59)

slbgz
Вот меня, кстати, удивило почему ты мне тут отвечал, хотя обещал игнорировать.

okkamas_knife
> ну и при чём тут они? или ты хочешь сказать что у меня всё без фавиконок?
Я хочу сказать, что 10 000 записей символов в 300 в среднем (вместе с шапкой, а то и меньше) каждая не могут занимать и 7 Мб.
Впрочем, фавиконок у тебя явно не много. Либо далеко не на все 10 000, либо очень много повторов. Ну и фавиконок конских размеров у тебя вероятно просто нет.

Добавлено 18-10-2011 22:18:17
> тогда логичный вопрос а почему разработчики до сих пор не сделают таким же образом работу с кэшем?
Вероятно им не хочется разрабатывать собственную файловую систему и они доверяют той, что есть? Кэш имеет свойство быстро устаревать и меняться, а потому внутренняя фрагментация данных может быть очень высокой, что явно не желательно.

Добавлено 18-10-2011 22:21:44
> почему в 3.6 нормально всё работает и без этих раздутий?
В 3.6 нет автоматической «вакуумизации» базы, а потому говорить о том, что там нормально работает — нельзя. Таблицы быстро физически перемешиваются внутри файла базы и получается довольно таки неудобоваримая каша, которая вызывает вполне реальные тормоза. Следствием чего и является появление всяческих вакуум-клинеров в форме расширений и внешних скриптов.
Тем не менее работать можно и с 3.6, просто так немного эффективнее. Это не даёт каких-то кардинальных преимуществ, но снижает физическую фрагментацию файла базы (но не внутреннюю, ей занимается сам SQLite).

> опять же я конечно понимаю что поиск по общей базе проще но не логичней ли отделять всётаки закладки от истории посещений?(да я в курсе что и в 3 всё в одном файле) тем более что чаще работа идёт именно с историей посещений
А примерно так оно и есть. Он в одной таблице держит закладки без адресов, а в другой — историю и адреса. Закладки выбираются из двух таблиц сразу. История из одной. Держать таблицы в разных файлах или одном — заметной роли не играет.
Поставь себе вот это и поизучай, например: https://addons.mozilla.org/en-US/firefox/addon/sqlite-manager/
Закладки связываются с адресами по колонке fk в таблице закладок и основному ключу (кажется id) в таблице адресов. В таблице закладок хранятся имена и структура закладок и папок.
При записи эти таблицы физически смешиваются, но во время простоя фокс выполняет (средствами SQLite) дефрагментацию таблиц базы.

Кстати, если учесть, что адресная строка работает как с закладками, так и с историей, то выносить в разные базы как-раз нелогично.

Добавлено 18-10-2011 22:40:52
> весь разговор собственно о том что с некоторого времени разработчики стали действовать нелогично в результате чего страдает ФФ и его юзеры.
Как видишь своя логика в этом есть.
Только проблема в том, что мы с тобой рассуждаем, а они эксперименты проводят и замеры как быстрее, как лучше, а не просто придумывают «что бы ещё такое эдакое сделать, авось быстрее будет работать и ни чего не сломаем».
Зато так у них дизайнерский отдел работает, хотя замеры они тоже проводят, но в дизайне интерфейса не всё можно измерить.

Отредактировано Lain_13 (18-10-2011 22:43:33)

okkamas_knife
У тебя много идей. Сделай им патчи, которые их реализуют и сравни производительность. Может ты действительно умнее их всех вместе взятых и они ошибаются.
Я понятия не имею почему кэш у них не на SQLite. Скорее всего потому, что им крайне впадлу переписывать код того, что есть, на корню. Они его немного подлатали и ускорили, и на том успокоились. Раньше он всё в одну папку валил, а теперь в разные (там есть проблема со скоростью считывания списка файлов из каталога при большом списке). У них и так много идей, и видимо этой либо нет, либо они не придают ей значения.

Кстати, для кэша использовать SQLite, с моей точки зрения, не логично. Это плоская база ключ-значение, где ключ — хэш адреса, а значение — содержимое файла по этому адресу. Т.е. при запросе файла вычисляется хэш адреса и выполняется поиск его на винте. Причём ускоряется поиск парой уровней папок по первым знакам из хэша. SQLite слишком накладен для такой простой операции. Ему, например, нужно распарсить полученный SQL-запрос, а зачем это нужно если он всегда одинаковый и только хэш меняется? Ни в одном серьёзном проекте что-либо основанное на SQL для таких целей долго не живёт, либо вырождается до вызова сохранённого запроса.
Т.е. если и делать на основе базы данных, то на основе чего-то более простого и быстрого, чем SQLite. Возможно текущий вариант и является этим чем-то, возможно — нет.

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

> ты будешь таки удивлён но я им очень давно пользуюсь.
Ни капли не удивлён. Все, кого интересуют файлы баз фокса, его как минимум хоть раз ставили. Просто хочу быть уверен, что и ты тоже.

> 2 кто мешает функцию вакуум очистки встроить в ФФ и запускать например когда ФФ свёрнут более минуты(ессно не каждый раз а учитывая изменения в базах)
Да ни кто не мешает. Она появилась в 4.0, на сколько я помню, но теперь её изменили так, что она не сокращает меньше N*10 метров, где N — количество полностью или частично занятых блоков.
А вот как часто и когда именно запускается — понятия не имею. Думаю раз в минуту делать точно не стоит — не слишком-то тривиальная процедура и на процессор давит заметно при большой базе. Тем более если не во время простоя, а просто в свёрнутом состоянии.

Добавлено 19-10-2011 00:32:46
> 1 зададим простой вопрос В какой таблице чаще происходять изменения - в закладках или в истории?
Да, в истории. Кстати, а какой профит от вынесения таблицы букмарков ты видишь? Они вообще почти не обновляются, а значит и смешивание с историей самое минимальное, и довольно быстро устраняется автоматической дефрагментацией базы.
Т.е. хоть ты их вынеси, хоть оставь на месте, а тут скорее только минус — необходимость работать с двумя разными базами. Почему минус? Вероятно SQLite банально не умеет делать выборку из двух баз одним запросом, а значит join закладок и истории для адресной строки придётся делать средствами браузера, что не фонтан. Как это проверить — понятия не имею.

Отредактировано Lain_13 (19-10-2011 01:14:09)

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

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

я просто смотрю по своей бывшей конторе где программы под практически одни и те же задачи писались старым поколением еще на 486 и первых пнях и работают шустро и нетребовательны к ресурсам и программы написанные новым поколением которым нужно для тех же самых задач минимум Р2-800 с 512 оперативы плюс в винду надо доставить всякого мусора типа .net  а разница только в интерфейсе и более красивой картинке да и скорость обсчета данных не впример ниже выходит.

МоФо имхо слишком увлеклась конкурентной борьбой причем не за счет качества продукта а засчет маркетинга
(всякой рекламы там рюшечек упаковки)
Это как с продуктами, вначале выходит офигенное качество,делается имя а потом продукт становится г..м

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

я этим немного занимался когда приспичило но бросил ибо мозги сильно занимает.
а насчет оптимизации

Добавлено 19-10-2011 02:13:35

моя не настолько хорошо знает буржуйский для этого.
это скорее печально чем грустно.
у меня пока есть инструменты для работы в сети которые меня устраивают,а доказывать комуто чтото учитывая что на 99% это зря потраченное время мне лень. тем более что крылатая фраза В.С.Черномырдина
применима ко всему миру.

я вижу только то что вижу. 
главное что? чтоб овчинка выделки стоила, в случае с тем кодером она того стоит.
если в программе размером в 10мег  и имеющей 100 функций появляется еще 5 и немного меняется интерфейс и при этом программа начинает занимать уже 50мег то нафиг оно нужно?

Отредактировано okkamas_knife (19-10-2011 02:13:35)

я приводил пример безотносительно фф.
то что фф пока ещё развивается я согласен.

часто развитие завершается превращением в монстра и смертью.
надо уметь останавливаться.
для ФФ было бы выходом нудное неспешное допиливание 3.6 с вычисткой и оптимизацией кода исправлением багов а фичи только самые необходимые исключительно относящиеся к безопасности типа модальных окон.
а параллельно с нуля делать новый проект в котором нет старого кода а если и берётся то только тот который уже лучше никак не напишешь.
тогда и от застарелых багов-глюков можно было б избавиться и организовать по уму плюнув на совместимость
ессно заранее подготовив средство миграции на новый проект..

Еда закончилась?