Примерно с 6-ой версии стал замечать что работа с закладками стала медленной.
Выглядит это примерно так: беру вкладку и перетаскиваю её в некоторую папку закладок (т.е. добавляю в закладки), страница добавилась. После этого в интерфейсе наблюдается некоторая "задумчивость" (выделяемая папка в закладках не подсвечивается, иногда бывает что недоступно контекстное меню для какой то закладки или для папки если хочется произвести сортировку).
Вот сейчас например, в одну папку накидал 10 закладок, после этого удаляю одну закладку, она удалилась, но перемещая курсор по оставшимся 9-ю закладка не происходит их "подчёркивание" и такое может длиться 5-10 сек, и подобное происходит при любой работе с закладками, любое изменение приводит к подобным паузам.

Не то что бы это сейчас очень критично, но в целом неприятно, посему вопрос: это нормальное или аномальное поведение?

- - - - -
Firefox 7.0.1 из PPA Mozilla
Кол-во закладкок: 2900
Размер places.sqlite: ~63Мб
"Причёсывание" всех *.sqlite файлов происходит средствами sqlite3

У меня примерно 4000 закладок, places.sqlite весит ~12 Мб. Попробуйте сделать чистку истории и вакуумизацию базы: PlacesCleaner :: Add-ons for Firefox.

hydrolizer спасибо за плагин, воспользовался им, но файл похудел не сильно, стал весить 52Мб.

После этого решил покапаться в базе и выяснить какая из таблиц самая большая.
Оказалось, что самая тяжёлая (в экспортированном виде) moz_places ~16Мб (более 170 тыс. записей), я так понял что там и закладки и история хранится.
Короче, грохнул всю историю все заполненные поля ииии после загрузки браузера получаю ~10Мб places.sqlite

Кстати говоря, выяснилось что скрипт достаточно долго не сжимал файл потому что: places.sqlite - Error: file is encrypted or is not a database, вон оно как.

Посмотрю насколько всё изменилось.

10 056 закладок places.sqlite 7.2 Мб.
чяднт?

Может, у меня хранится больше фавиконок. Может, больше аннотаций. Может, еще что-то.
Если в консоли прогнать вот такой код:

Components.utils.import("resource://gre/modules/Services.jsm");
var mDBConn = Components.classes["@mozilla.org/browser/nav-history-service;1"]
    .getService(Components.interfaces.nsPIPlacesDatabase).DBConnection;
var stmt=mDBConn.createStatement("select name from sqlite_master where type='table' and name like 'moz%'");
var tables=[];
while(stmt.step()) tables.push(stmt.row.name);
stmt.finalize();
Services.console.logStringMessage(tables.map(function(t)
{
  try
  {
    stmt=mDBConn.createStatement("select count(*) cnt from "+t);
    stmt.executeStep();
    return t+": "+stmt.row.cnt;
  }
  finally
  {
    stmt.finalize();
  }
}).join("\n"));
Services.console.logStringMessage("done");

то на моем текущем профиле он показывает такие результаты:

moz_bookmarks:  3860
moz_bookmarks_roots:  5
moz_keywords:  0
moz_favicons:  1375
moz_annos:  2430
moz_anno_attributes:  13
moz_items_annos:  3489
moz_places:  8137
moz_historyvisits:  32705
moz_inputhistory:  124

hydrolizer
moz_historyvisits:  32705
вот оно

Совсем не оно. Случайно заметил, сколько весит places.sqlite в свежесозданном профиле - 10 Мб. Отличие по размеру от моего достаточно старого и совсем не свежего places.sqlite в действующем профиле небольшое.

С некоторых пор (с 4.0, вроде бы) размер places.sqlite стал кратным 10 мегабайтам. Оптимизация какая-то, надо полагать.

только что проверил мдяяяя
короче свежесозданный профиль без ничего
создал-вышел-удалил places.sqlite,bookmarks.html,и содержимое bookmarkbackups
запустил фф снова - вышел смотрю
7ка places.sqlite 10 мб
3.6 places.sqlite 140 кб

фейспалм.
вот что они туда пихают???? этож [пииип] стыд!

17-10-2011 09:07:02

за такую "оптимизацию" бить надо палками!

okkamas_knife
Да ничего туда не пихают, можно сделать БД vacuum и сильно уменьшить размер... до первого перезапуска.
Я думаю, это может быть от фрагментации жесткого диска – размер как раз округляется до 10 Мбайт.

не точно не это.
размер кластера в нтфс обычно 4кб,а 10мб кластеры мне чтото не встречались.
зачем они такое извращение сделали непонятно.

Нашелся некий баг на тему: https://bugzilla.mozilla.org/show_bug.cgi?id=616019

17-10-2011 10:19:52
И Avoid sqlite fragmentation via SQLITE_FCNTL_CHUNK_SIZE – там в патче

+  // Grow places in 10MB increments
+  mDBConn->SetGrowthIncrement(10 * 1024 * 1024, EmptyCString());

Ошибаетесь, у меня есть 4Мб и 6Мб

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

Ввиду чего? Эти 10 Мб так критичны для размера ваших носителей?

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

почему раньше люди писали компактный и быстрый код а сейчас пишут большой и тормозной?деградация?

Вы кому-то куда-то по сети передаете этот файл places.sqlite? Или вы о том, что этот файл передается, будучи запакованным в инсталлятор? Уверяю вас: не передается. Он создается самим FF - файл при первом открытии коннекта к places, таблицы - DDL-инструкциями. Если не верите - распакуйте дистрибутив, и попробуйте там найти хоть один файл .sqlite.

Вам доводилось сталкиваться с большими БД? Не задумывались, почему они при файлах данных в сотни гигабайт размером выдерживают транзакционную нагрузку в миллионы транзакций в секунду? В том числе потому, что их внутренее устройство учитывает неизбежную фрагментацию. И SQLite здесь не исключение. У меня, кстати, нет абсолютно никаких нареканий на скорость работы базы.

А если такие вещи хранятся в памяти, то они хранятся не в виде raw data, считанных из файла как есть, а в десериализованном в объекты/структуры виде. И сам размер файла здесь уже дело достаточно пятое.

Ну известно почему - потому же, почему раньше небо было голубее, люди добрее, и т.д и т.п.

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

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

как я написал в своём первом сообщении, у меня браузер после добавления закладки возвращался в полностью функциональное состояние через 5-10 сек, я считаю это не нормально, с такими задержками работать не комфортно, но возможно

кстати говоря, после всех описанных манипуляций, получил маленький и компактный places.sqlite, работа с закладками стала шустрей, но всё-таки проявляется некоторая "тупка" при добавлении новых закладок. у всех так?

у меня - не так, у тебя тоже будет не так если проследуешь по ссылкам в моей подписи...

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

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

hydrolizer, цитата не моя, поправь, пожалуйста

18-10-2011 14:16:53

задержки будут так как они не только от компактирования базы зависимы.

Я вижу здесь собрались люди, которые ни хрена не смыслят в базах данных и пытаются ругать мозилловцев за то, что они в них немного таки смыслят.
Гениально, просто гениально.

Давайте с вами поговорю я и мой воображаемый друг. Он будет задавать мне глупые вопросы, а я буду давать не менее глупые ответы.

— Почему размер файла кратен 10 Мб?
— Для избежания или, как минимум, уменьшения фрагментации при записи.

— Но он же имеет больше шансов фрагментироваться!
— Да, если писать его по кускам. Если отрезать кусок в 10 Мб сразу, то ОС постарается найти на жестком диске свободный кусок размером в эти 10 Мб. Так что этот кусок в 10 Мб как-раз имеет самые минимальные шансы оказаться фрагментированным. Разве что ты забил винт фотками до отказа, а потому удалил несколько случайных фотографий в разных местах и после этого запустил фокс первый раз и он создал на этом винте этот файл. Да, в таком случае у системы просто не будет выхода кроме как разделить эти 10 Мб на фрагменты.

— Но он же жрёт место на винте!
— 10 Мб это меньше 1% от 1 Гб, у тебя винт как минимум на 60 таких Гб. Всё ещё жрёт? Снеси один фильм или почисти свою коллекцию музыки наконец. Вот уж что точно жрёт место.

— Но он будет долго грузиться!
— Кто тебе ляпнул, что он сразу грузится целиком? Кто тебе сказал, что грузятся пустые блоки?! Более того, даже при необходимости выполнить выборку из базы подгружаются только необходимые таблицы. Причём опять же не факт, что целиком.

— Синхронизация!
— И?
— Дофига же!
— При синхронизации передаются только изменения.

— А если профили на сервере?
— А если вы извращенец? Кэш лежит в профиле, обновляется куда чаще и занимает в разы больше. Всё ещё храните профили на сервере? Ах да, его можно выключить, но это увеличит расход траффика на перекачку того, что могло бы лежать в кэше. Локально. У пользователя. Да, у вас может быть свой кэширующий прокси, но это всё равно медленнее, чем считать файл с винта.
— …
— А вот иногда делать бэкапы на сервер ни кто не мешает если это вообще нужно. Как вариант — можно поднять локальный сервер синхронизации и вся важная для пользователей информация будет бэкапиться на сервер в полностью автоматическом режиме. Причём передаваться будут только изменения, что сильно сократит объём передаваемой информации.

slbgz
Твоя двойка вообще про базы данных ни сном, ни духом. У тебя все твои закладки лежит в XML-подобном чудовищном файле, который действительно читается целиком при загрузке и парсится тогда же. Естественно его _нужно_ держать в памяти до загрузки фокса если хочешь, чтоб фокс быстро запустился и быстро с ним работал. А если учесть, что для обновления его на винте его необходимо перезаписать целиком, то тут просто выхода нет.  Вынос же профиля с places.sqlite в память существенно в работе с закладками ни чего не изменит.

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

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

кто вам это сказал?
и кстати объясните почему именно 10мб а не 16 или  5 или не 100?

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

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

а про бездисковые станции вы и не слышали?

ага-ага и с каких это пор синхронизация передаёт только кусочки файла?
если  будет синхронизироваться то будут передаваться те 10мб целиком.

всё так.

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 или что-то вроде, то копировать будешь все новые файлы.

О, мой проклятый склероз! Я опять забыл, что «босс» и «миллионер, качающий торренты» в одном лице все знает лучше всех и ему не нужно даже спрашивать «пациента» о его «жалобах», «истории болезни» и т.д. Босс-шерлок-холмс видит насквозь как рентгеном каждого «глупыша»
(command: флажок «временно разрешить вывод из игнора» установить в false).

Остальным благодарным слушателям скромно сообщу, что «недоразумение», т.е. конкретно 2-й Фокс  к идее размещения браузера на ramdisk не имел никакого отношения так как юзаю я его совсем немного - пару недель или чуть больше и перешел на него после того, как годы вкушал  все «преимущества» быстродействия и строения баз «эффективных» «последующих версий», которые и переносил на ramdisk. Преимущество 2-го Фокса состоит лишь в том, что сам он занимает в 2 раза меньший объем, что позволяет более безболезненно размещать его целиком, а не только профиль или кеш на ramdisk'e машин с ограниченной максимальной величиной памяти.

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

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

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

подозреваю что всётаки первое и решали это походу не программеры которые сделали бы размер кратным степени двойки.

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

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

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

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

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

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

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

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

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

весь разговор собственно о том что с некоторого времени разработчики стали действовать нелогично в результате чего страдает ФФ и его юзеры.

ну и при чём тут они? или ты хочешь сказать что у меня всё без фавиконок?

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
> весь разговор собственно о том что с некоторого времени разработчики стали действовать нелогично в результате чего страдает ФФ и его юзеры.
Как видишь своя логика в этом есть.
Только проблема в том, что мы с тобой рассуждаем, а они эксперименты проводят и замеры как быстрее, как лучше, а не просто придумывают «что бы ещё такое эдакое сделать, авось быстрее будет работать и ни чего не сломаем».
Зато так у них дизайнерский отдел работает, хотя замеры они тоже проводят, но в дизайне интерфейса не всё можно измерить.

ты будешь таки удивлён но я им очень давно пользуюсь.

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

а причем тут изобретать файловую систему?

любой загруженный объект будь он хтмл или картинкой становится элементом таблицы
с конкретными атрибутами типа адрес время кэширования итд итп
эта технология давно используется на куче форумов например где сообщения и приаттаченные файлы хранятся в одном общем файле базы.
опятьже в зависимости от атрибутов можно помещать элементы в разные части таблицы
то есть которые кэшируются надолго складывать вначало
которые кэшируются на короткое время в конец, что опять же уменьшит фрагментацию таблицы
в соседней таблице держать историю например причём сделать её нормально(а не как сейчас)
например так
юзер указал хранить историю столько то дней, делаем расчет скажем 750 посещений в сутки
(приблизительно страница в 2 минуты все 24 часа)
при выделении под урл 512 байт для хранения годовой базы потребуется файл гдето около сотни мег
на месяц ессно будет порядка 10 мег
причем фрагментация в таблице будет отсутствовать ибо урл пишутся последовательно
а дыры будут возникать только при удалении юзером истории за определёный период или вручную но это удаление легко совместить с вакуум очисткой.
ну и плюсуем к этому файлу в конец таблицу кэша размер который задаётся юзером.
в результате мы будем иметь одну нефрагметированную или слабофрагментированную базу с закладками в одном файле
и другой файл в котором слабофрагментированная таблица с историей вначале
и фрагментированная таблица с кэшем.
соответственно поиск из адресной строки будет более быстрый как и загрузка потому что действий для получения содержимого элемента нужно будет меньше
(найти элемент в таблице и дать запрос ОС на получение соответствующего куска уже открытого файла после чего ОС считает нужный кусок данных и отдаст его фф )
vs
(найти элемент в таблице узнать с каким именем файла он сопоставлен и отправить ОС запрос на получение содержимого этого файла для чего ос придется найти этот файл по указанному пути открыть его для чтения и передать данные фф )

логично же?

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:47

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

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

Пару лет тому назад у Никонова читал о страшном, просто катастрофическом упадке системы образования на примере Франции во всем мире... Это длится уже годы и десятилетия и вот результат не заставил себя ждать. Майк Джадж неспроста свой фильм сделал именно об этом...  5 лет тому назад, а с тех пор становится все хуже и хуже. Мрак надвигается... полный мрак, без шуток. Ты видишь, что со многими ... уже стало невозможно разговаривать, они просто говорят на другом языке.

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

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

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

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

okkamas_knife
> но думаю это нафиг не надо если так нужна скорость
А несколько раздельных запросов вместо одного думаешь будут работать быстрее? Я прямо таки уверен, что нет.

> ну и никто не мешает завести отдельную таблицу чисто для адресной строки с наиболее часто посещаемыми сайтами скажем на 15-30 урлов
Ты же не думаешь, что они каждый раз каунт по домену делают? У них это кэшируется и берётся из отдельной таблицы. А ещё есть кэш вводимых слов в адресную строку и что ты при этом выбрал, чтоб в следующий раз предложить именно это.

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

19-10-2011 01:48:29
> но сам понимаешь это нереально.
Да, но ты можешь открыть им багрепорт, нарисовать схему того, как должен работать быстрый кэш и чем он лучше того, что есть.
Схему как должна работать более быстрая база и чем она лучше старой. Будешь с ними обсуждать своё решение и докажешь, что это действительно важно и лучше того, что есть.
Иначе все твои размышления на счёт того, как лучше было бы сделать, не имеют смысла. Их всё равно ни кто не реализует.
Понимаешь на сколько это грустно?

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

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

19-10-2011 02:13:35

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

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

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

> это скорее печально чем грустно.
Да, пожалуй так.

> уже 50мег то нафиг оно нужно?
Ты преувеличиваешь. Я тут с Розенфельдом недавно простенькие замеры запуска с пустым профилем проводили 10 и 3.6, и разница была где-то до полутора. Не сказал бы, что критично, да и функции не простые и довольно интересные добавились за это время. Одно декодирование видео чего стоит из HTML5, а WebGL? Я его недавно в линуксе гонял — работает, зараза. А поддержка CSS3 селекторов? Новый куда более шустрый JS-движок и прочее, прочее… Как оказалось памяти конкретно добавляют история/закладки (кто б сомневался, как минимум столько, сколько на винте) и некоторые расширения. С ними разница довольно быстро нивелируется. Так что пока Firefox скорее развивается, чем тупо толстеет и это хорошо.

Но давай прекратим, а то мы в какой-то полный оффтоп уже укатились.

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

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

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