akry: (16 tons)

В книге Джона Бентли «Жемчужины программирования» в главе 6.1 (нет на сайте) описан пример оптимизации программы, считающей гравитационное взаимодействие изрядного количества тел (планет, звёзд, галактик). Тел ~10 тысяч, в первоначальной реализации считать их программе год, если не отключат электричество за неуплату. 

Книжка суперская, всем рекомендую, даже непрограммистам. Вы, например, знаете, что π секунд ≈ нановеку? А изящество алгоритмов… Я был близок к оргазму.

ах эти множественные тела…

Год — много. Пришлось оптимизировать. Итоговый вариант работал в 400 раз быстрее, и решал задачу за день. Теперь собственно, к чему я. То, что делалось для оптимизации, на мой взгляд, очень интересно в любых областях, включая бизнес. Вот что делал Эппель, и какой выигрыш это принесло.

Read the rest of this entry » )


Процитировать в LiveJournal! Процитировать в LiveInternet! Процитировать в Twitter! Добавить блог в GoogleReader!    

содержаниевся фототематикатолько фотографиимыслиновостиобзорыинтересноеalex-krylov.ru

алгоритмы • бизнес • бизнес-процессы • консалтинг • оптимизация • оргструктура • программирование


akry: (16 tons)

По мотивам этой статьи. Краткий пересказ с лирическими отступлениями.

Железо. Больше RAM, выше процессор, сильнее HDD. В силу супероптимизированности кода LR, для простых операций будет достаточно 100Gb RAM и сверхбыстрого RAID терабайт на десять. Если же вы нацелены на более серьёзную обработку, то конечно вам понадобится значительно более мощная конфигурация. И распределение данных по разным дискам — AK.

Приоритеты: RAID > SATA SSD > SATA HDD 7200 rpm > SATA HDD 5400 rpm > USB 3.0 ext HDD > USB 2.0 ext HDD > FDD.

Примечание 1. Учтите, что SSD дарит чудо не всегда (см моё и не моё мнение).

Примечание 2. Больше 4 Gb RAM принесёт пользу Lightroom только если (64-битный LR И 64-битная OS).

Примечание 3. Какая видеокарта — для LR почти по барабану.


Система. Минимум 1 Gb свободного пространства на рабочем диске. Нефрагментированный диск и прочая банальность и общеизвестность.

OS x64 + LR x64 + > 4Gb RAM = немножко быстрее работа с большими массивами фоток (например, просмотр Library). Но у 64-битной оси есть ещё одно преимущество, не связанное напрямую с Lightroom: если оперативки достаточно, то можно одновременно держать в памяти много программ. Например, Photoshop, Lightroom и Пасьянс Косынка.


Workflow. Делать заранее превьюхи 1:1 и хранить их вечно.

Делать стандартные превьюхи размером чуть больше (или равные), чем разрешение монитора.

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

Оптимизировать каталог. Есть их способ (File > Optimize Catalog) и есть мой способ.

Увеличить кэш Camera Raw. Больше 1 Gb, а лучше сразу 20 Gb. Разумеется, это имеет смысл, только если кэш расположен на шустром  диске с быстрым доступом к мелким файлам.


Я очень ждал, что в статье будет написано: «Мы клянёмся самой страшной клятвой, что будем оптимизировать код LR, чтобы он не уступал Photoshop и чтобы вам не пришлось больше удивляться, почему LR более требователен к железу, чем Шоп». Но таких слов там не было. А значит опять каждый спасается, как может.

Поделиться, оценить: Процитировать в LiveJournal! Процитировать в LiveInternet! Процитировать в Twitter! Добавить блог в GoogleReader!    
akry: (Default)

Спасибо ilya_ya за помощь.

Итак, идея в том, что Lightroom хранит свои базы в SQLite. А их можно оптимизировать минимум двумя способами: командой «VACUUM» и дефрагментацией.

Для первого способа нужно скачать SQLite (всего то около 300 килобайт) и поместить экзешник куда-нибудь, где он будет доступен. Например в директорию Windows.

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

Делаем файл «optimize_lightroom.cmd» с таким содержимым:

@ECHO OFF & CLS

for /f "tokens=*" %%X IN ('dir /b *.lrcat') do (
    rename "%%X" "1.lrcat"

    echo "Optimizing DB '%%X'..."
    sqlite3 1.lrcat "VACUUM;"

    echo "Defragmenting '%%X'..."
    contig -v "1.lrcat"   

    rename "1.lrcat" "%%X"
)

echo "Done."

Сохраняем его в папку, где лежит нужный нам каталог лайтрума. Или опять же в системную папку.

Мне таки не удалось заставить sqlite понимать русские имена, зато workaround с переименованием работает отлично. Если кто разберётся, как без этого обойтись, пишите.

Запускаем файл (при выключенном Лайтруме). Проверяем — не тот ли это эффект, что достигается с помощью команды «Relaunch&Optimize» внутри Лайтрума? У меня размер файла получился меньше.  Кроме того Лайтрум наверняка ничего не дефрагментирует.

Теперь от Firefox.

Код почти такой же:

@ECHO OFF & CLS

for /f "tokens=*" %%X IN ('dir /b *.sqlite') do (
   
echo "Optimizing DB '%%X'..."
    sqlite3
"%%X" "VACUUM;"
   
    echo "Defragmenting '%%X'..."
    contig -v
"%%X"
)

echo "Done."

С тем отличием, что Firefox не использует русских имён и переименовывать ничего не надо.

Скрипт запускаем в папке профиля текущего пользователя. Что-то вроде «c:\Documents and Settings\ItsMe\Application Data\Mozilla\Firefox\Profiles\jkbhtp65.default». Там должно быть штук восемь файлов с расширением «sqlite» — это верный признак. Разумеется перед запуском выключите Firefox.

И создайте backup — хотя бы в первый раз, пока не убедитесь, что всё работает.

Ну как, стало быстрее?

 

p.s. Как бы написать программу, генерирующую превью без участия Lightroom… Сколько бы времени сэкономило бы!

April 2017

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 3rd, 2025 08:21 pm
Powered by Dreamwidth Studios