Полезная информация

Общайтесь со знакомыми и друзьями в нашей группе в Контакте.

№2618-10-2011 17:44:27

slbgz
Забанен
 
Группа: Members
Зарегистрирован: 27-06-2011
Сообщений: 246
UA: Firefox 2.0

Re: Медленная работа с закладками

Lain_13 пишет

Да, в таком случае у системы просто не будет выхода кроме как разделить эти 10 Мб на фрагменты.

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

Lain_13 пишет

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

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

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

Отсутствует

 

№2718-10-2011 18:47:28

okkamas_knife
We are the Borg.       Resistance is futile.
 
Группа: Members
Зарегистрирован: 21-10-2009
Сообщений: 9558
UA: Firefox 3.6

Re: Медленная работа с закладками

Lain_13 пишет

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

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

Lain_13 пишет

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

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

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

Lain_13 пишет

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

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

Lain_13 пишет

Причём передаваться будут только изменения, что сильно сократит объём передаваемой информации.

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

Lain_13 пишет

а я буду давать не менее глупые ответы.

всё так.


я помню те времена когда обновления программ убирали проблемы и исправляли баги, а не добавляли их.
toxID:05AB9B827D896AACEE7FF4573A02FB8F025F46ADC856B98F65BC1BA9BD21A81DC98BA9C36CE3

Отсутствует

 

№2818-10-2011 18:58:05

Lain_13
Забанен
 
Группа: Members
Откуда: Волшебная Страна
Зарегистрирован: 26-04-2006
Сообщений: 10320
UA: Nightly 10.0

Re: Медленная работа с закладками

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)

Отсутствует

 

№2918-10-2011 19:47:44

slbgz
Забанен
 
Группа: Members
Зарегистрирован: 27-06-2011
Сообщений: 246
UA: Firefox 2.0

Re: Медленная работа с закладками

Lain_13 пишет

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

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

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

Отредактировано slbgz (18-10-2011 20:18:08)

Отсутствует

 

№3018-10-2011 19:57:22

Lain_13
Забанен
 
Группа: Members
Откуда: Волшебная Страна
Зарегистрирован: 26-04-2006
Сообщений: 10320
UA: Nightly 10.0

Re: Медленная работа с закладками

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

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

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

Отсутствует

 

№3118-10-2011 20:03:38

okkamas_knife
We are the Borg.       Resistance is futile.
 
Группа: Members
Зарегистрирован: 21-10-2009
Сообщений: 9558
UA: Firefox 3.6

Re: Медленная работа с закладками

Lain_13 пишет

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

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

Lain_13 пишет

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

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

Lain_13 пишет

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

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

Lain_13 пишет

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

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


я помню те времена когда обновления программ убирали проблемы и исправляли баги, а не добавляли их.
toxID:05AB9B827D896AACEE7FF4573A02FB8F025F46ADC856B98F65BC1BA9BD21A81DC98BA9C36CE3

Отсутствует

 

№3218-10-2011 20:09:47

Lain_13
Забанен
 
Группа: Members
Откуда: Волшебная Страна
Зарегистрирован: 26-04-2006
Сообщений: 10320
UA: Nightly 10.0

Re: Медленная работа с закладками

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

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

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

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

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

Отсутствует

 

№3318-10-2011 20:42:43

slbgz
Забанен
 
Группа: Members
Зарегистрирован: 27-06-2011
Сообщений: 246
UA: Firefox 2.0

Re: Медленная работа с закладками

slbgz пишет

(command: флажок «временно разрешить вывод из игнора» установить в false). :lol:

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

Отредактировано slbgz (18-10-2011 20:53:00)

Отсутствует

 

№3418-10-2011 21:24:59

Lain_13
Забанен
 
Группа: Members
Откуда: Волшебная Страна
Зарегистрирован: 26-04-2006
Сообщений: 10320
UA: Nightly 10.0

Re: Медленная работа с закладками

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

Отсутствует

 

№3518-10-2011 22:11:34

okkamas_knife
We are the Borg.       Resistance is futile.
 
Группа: Members
Зарегистрирован: 21-10-2009
Сообщений: 9558
UA: Firefox 3.6

Re: Медленная работа с закладками

Lain_13 пишет

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

Lain_13 пишет

ну а система уже переписывает соответствующие ему физические кластеры. Но не весь файл целиком.

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

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




Lain_13 пишет

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

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


я помню те времена когда обновления программ убирали проблемы и исправляли баги, а не добавляли их.
toxID:05AB9B827D896AACEE7FF4573A02FB8F025F46ADC856B98F65BC1BA9BD21A81DC98BA9C36CE3

Отсутствует

 

№3618-10-2011 22:14:20

Lain_13
Забанен
 
Группа: Members
Откуда: Волшебная Страна
Зарегистрирован: 26-04-2006
Сообщений: 10320
UA: Nightly 10.0

Re: Медленная работа с закладками

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)

Отсутствует

 

№3718-10-2011 23:31:40

okkamas_knife
We are the Borg.       Resistance is futile.
 
Группа: Members
Зарегистрирован: 21-10-2009
Сообщений: 9558
UA: Firefox 3.6

Re: Медленная работа с закладками

Lain_13 пишет

Поставь себе вот это и поизучай, например: https://addons.mozilla.org/en-US/firefox/addon/sqlite-manager/

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

Lain_13 пишет

В 3.6 нет автоматической «вакуумизации» базы, а потому говорить о том, что там нормально работает — нельзя. Таблицы быстро физически перемешиваются внутри файла базы и получается довольно таки неудобоваримая каша, которая вызывает вполне реальные тормоза.

Lain_13 пишет

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

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

Lain_13 пишет

Держать таблицы в разных файлах или одном — заметной роли не играет.

Lain_13 пишет

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

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

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

логично же?


я помню те времена когда обновления программ убирали проблемы и исправляли баги, а не добавляли их.
toxID:05AB9B827D896AACEE7FF4573A02FB8F025F46ADC856B98F65BC1BA9BD21A81DC98BA9C36CE3

Отсутствует

 

№3819-10-2011 00:23:54

Lain_13
Забанен
 
Группа: Members
Откуда: Волшебная Страна
Зарегистрирован: 26-04-2006
Сообщений: 10320
UA: Nightly 10.0

Re: Медленная работа с закладками

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)

Отсутствует

 

№3919-10-2011 00:47:05

slbgz
Забанен
 
Группа: Members
Зарегистрирован: 27-06-2011
Сообщений: 246
UA: Firefox 2.0

Re: Медленная работа с закладками

Lain_13 пишет

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

Я ж говорю, что я - забывчивый …
Ну, вот - опять забыл. :lol:

З.Ы. С тобой можно разговаривать, Lain_13, но лучше не начинать спорить и доказывать что-либо, - бесполезно... а вот - о погоде, о футболе... - нет проблем, сколько угодно...   и - на другие темы, которые мне безразличны абсолютно :lol:

Добавлено 19-10-2011 01:14:47

okkamas_knife пишет

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

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

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

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

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

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

Отсутствует

 

№4019-10-2011 01:22:34

okkamas_knife
We are the Borg.       Resistance is futile.
 
Группа: Members
Зарегистрирован: 21-10-2009
Сообщений: 9558
UA: Firefox 3.6

Re: Медленная работа с закладками

Lain_13 пишет

одним запросом, а значит join закладок и истории для адресной строки придётся делать средствами браузера, что не фонтан. Как это проверить — понятия не имею.

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

Lain_13 пишет

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

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

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

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

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


я помню те времена когда обновления программ убирали проблемы и исправляли баги, а не добавляли их.
toxID:05AB9B827D896AACEE7FF4573A02FB8F025F46ADC856B98F65BC1BA9BD21A81DC98BA9C36CE3

Отсутствует

 

№4119-10-2011 01:30:10

Lain_13
Забанен
 
Группа: Members
Откуда: Волшебная Страна
Зарегистрирован: 26-04-2006
Сообщений: 10320
UA: Nightly 10.0

Re: Медленная работа с закладками

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

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

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

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

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

Отсутствует

 

№4219-10-2011 01:58:41

okkamas_knife
We are the Borg.       Resistance is futile.
 
Группа: Members
Зарегистрирован: 21-10-2009
Сообщений: 9558
UA: Firefox 3.6

Re: Медленная работа с закладками

Lain_13 пишет

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

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

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

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

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

Lain_13 пишет

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

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

Lain_13 пишет

Ты же видишь только тёмную сторону.

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

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


я помню те времена когда обновления программ убирали проблемы и исправляли баги, а не добавляли их.
toxID:05AB9B827D896AACEE7FF4573A02FB8F025F46ADC856B98F65BC1BA9BD21A81DC98BA9C36CE3

Отсутствует

 

№4319-10-2011 04:14:32

Lain_13
Забанен
 
Группа: Members
Откуда: Волшебная Страна
Зарегистрирован: 26-04-2006
Сообщений: 10320
UA: Nightly 10.0

Re: Медленная работа с закладками

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

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

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

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

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

Отсутствует

 

№4419-10-2011 05:09:24

okkamas_knife
We are the Borg.       Resistance is futile.
 
Группа: Members
Зарегистрирован: 21-10-2009
Сообщений: 9558
UA: Firefox 3.6

Re: Медленная работа с закладками

Lain_13 пишет

> уже 50мег то нафиг оно нужно?
Ты преувеличиваешь.

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

Lain_13 пишет

Всегда можно сделать лучше, чем было, но нужно ещё и в разумные сроки укладываться, и развиваться.

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

Lain_13 пишет

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

Еда закончилась? :P
4def88eee86ac58be4e3fc4c13afcae5.jpg


я помню те времена когда обновления программ убирали проблемы и исправляли баги, а не добавляли их.
toxID:05AB9B827D896AACEE7FF4573A02FB8F025F46ADC856B98F65BC1BA9BD21A81DC98BA9C36CE3

Отсутствует

 

Board footer

Powered by PunBB
Modified by Mozilla Russia
Copyright © 2004–2020 Mozilla Russia GitHub mark
Язык отображения форума: [Русский] [English]