>А вот идею с SSD гигабайта на 64 я, если честно, не понял.
Всё очень просто :D SSD на 16Гб сделаны ещё по старым технологиям и не такие быстрые. 32Гб из-за малой распространённости сегодня стоят _дороже_, чем на 64 :)
Я ориентируюсь сейчас конкретно на TS32GSSD25S-M (~7600руб) и TS64GSSD25S-M (~6200р.)
>Имхо, все необходимые куски системы вполне можно впихнуть в 4 гига (а то и меньше, смотря что и как пихать).
Ну, у меня на домашнем десктопе /usr сейчас 28Гб. И /opt на 2Гб.
>но забывать по /bin и /sbin, а также про /lib — считаю ошибкой =)
Угу, ты прав. Так что 32Гб мне не хватит ;)
>А вот /tmp вообще лучше всего в памяти развернуть, если позволяет.
4Гб позволяет ;) (точнее, 3,3Гб, ибо PAE и x86_64 меня пока не привлекают :)) И /var/tmp/portage там же.
>Идея заключается в том, что когда системе нужна конкретная функция из этой библиотеки, размером, скажем, 2 кб (нормальный размер для откомпилированного кода одной функции, так?),
Идея прекрасная :) Но фишка в том, что никакому приложению не нужно грузить по одной функции :D И функции они грузят целыми кодоблоками, в наше время на сотни килобайт порой, и ресурсы грузят мегабайтами.
Да, наверное, на машине с 512Мб и Вистой, сожравшей все эти 512Мб, реально получить выигрышь в несколько процентов, что и показывает тест Tom's Hardware, но как только в дело вступает банальная предварительная выборка, никакого выигрыша флешка уже не даст.
>Да, для SSD-накопителя ReadyBoost особой разницы не даст
Да, вообще не даст, а вчистую продует _в любых_ условиях :) Время доступа у SSD меньше, скорость чтения — НАМНОГО выше.
>Впрочем, людям, у которых есть prelink и Gentoo, ReadyBoost не нужен.
prelink — несколько не то. А так — я планирую взять себе SSD гигабайта на 64, как только цены упадут до ~$150. Закинуть туда /opt со /usr и опаньки :) Благо, в Linux очень легко отделить части системы друг от друга.
Это даже не смешно :D Даже на 512Мб ускорение составляет 0,5-2 секунды от 2-9 секунд. Это всё на уровне погрешности измерений. Благо под Windows точный стартап приложения измерить просто невозможно.
А тут на форуме у людей Фотошоп с 8 секунд за 4 запускаться начинает. Идите сообщите Том'c Хардваре, что у них результаты не отражают действительность :)
>и дальше по требованию такими-же блоками будет проецироваться в память.
А проецироваться она будет через астрал? :)
Нет, через те же запросы чтения. И как закажет приложение хотя бы иконку одну хайрезную на 50кБ — всё, уже флешка уступает. Закажет десяток иконок подряд из одного ресурса — не просто уступает, а прямо пролетает :)
…
Ну поставь ты портейбл версию того же Firefox на флешку и на HDD и сравни время запуска. И вопросы тут же отпадут :)
Десяток dll'ек по 500кБ — это 5Мб. 2 секунды загрузки с USB без учёта латентности.
Для HDD это десяток перемещений/поисков по 6мс, т.е. 60мс + десяток чтений, т.е. 5Мб при скорость 50Мб/с — 0.1 сек. Итого, 0.16 сек. Те же самые 12.5 раз, пропорции не изменятся, т.к. в предыдущем расчёте считался полный цикл.
Кстати, если файлы будут больше размером, то разрыв начнёт увеличиваться. Если меньше — уменьшаться. Можно посчитать, с какого размера. Но тут надо учесть собственную латентность USB-флешек, это около 1мс. Тогда скорость доступа к файлам сравняется на размере S = Sf*Sh*(Ah-Af)/(Sh-Sf) = 50e6*2,5e6*(6e-3-1e-3)/(50e6-2,5e6) = 12,8кБ. Т.е. если размеры файла менее 15кБ, то флешка быстрее. Увы, размер это совершенно для системных файлов нехарактерный.
…
Правда, я тут упустил сперва, что речь идёт про ноутбучные HDD. У них время доступа похуже, бывает до 12мс. Тогда «равноскоростной» размер файла будет 28,2кБ. Но погоды это почти не сделает, всё лимитирует скорость чтения…
…
На самом деле, я наступал на эти грабли лет 8 назад. Мне как-то нахаляву попали 2 стареньких гигабайтных SCSI-диска. Старенькие, но SCSI же! :) И я их соединил в софтверный рейд. Время доступа по тем временам совсем какое-то смешное получилось. Всё это затеял я для того, чтобы туда своп кинуть. Как же я удивился, когда вместо ускорения система начала очень и очень ощутимо тормозить :) Небольшое исследование тут же показало, что всё упирается не во время доступа, а в скорость чтения…
Попробуйте расшифровать, что Вы хотели сказать этой фразой? Что на Java-фреймворках есть общие объекты? Это очевидно. Странно, если Вы считаете, что могут быть считающие иначе.
Тогда это не куриная слепота. А что-то с мышцами, отвечающими за диафрагменность зрачка. Тут моих общих знаний не хватит, я б рекомендовал к врачу обратиться. Витамины, боюсь, не особо помогут.
>поподробней подалуйста что вам не нравится в механизмах рефлексии PHP!
Всё нравится :) Я говорю, что мою идеологию можно реализовать на любом языке с развитой рефлексией. Сейчас использую PHP. Столь же легко сделать на Python или Ruby, Perl. Немного подумав, можно и на Java :) Чем и планирую заняться как будет время и желание…
Кстати, небольшой хинт: if(substr($str,0,1)=='_') работает _намного_ медленнее, чем if(preg_match('/^_/', $str)) :) Видимо, вся фишка в экономии на создании временной строки. Я когда-то Smarty так ускорил раз в 5, подменив массу substr или {} на соответствующие preg_*, особенно, когда после сравнения требовалось ещё и подстроки извлекать. Правда, было это во времена ~2.6.14. Патчи мои не приняли без комментариев, повторно уже не связывался :)
>Кстати!!! килограмм Кармы тому кто придумает избавиться от
ob_start();
Простого (и более быстрого, чем с перехватом) способа, ИМХО, не будет. Можно запретить в шаблоне любой вывод, сразу начинать его с "<?php..." и отказаться от всех echo в пользу $RESULT.="..."
:)
Кроме того, в моём случае можно написать обработчик не уровня рендерера тела страницы, а уровня генератора страницы в целом. Но тогда проще уже сделать шаг дальше и тупо писать отдельный PHP-скрипт, который и будет выводить всё сам (пусть и пользуясь для извлечения данных функционалом фреймворка).
>наскидку вижу что логика очень прозрачная
Это было одной из целей.
>это плюс, но много сущностей плодите
Есть такое, это обратная сторона микроядерности, модульности и многофункциональности. Компенсируется тем, что сущности все простые и унифицированные :)
Фактически, этот фреймворк — не столько набор кода, сколько набор правил и соглашений. Поэтому, когда придёт надобность, смогу быстро реализовать его на любом языке с развитой рефлексией (в ближайших планах Java, но не в области Web'а).
>Через 3 года после постоянной работы за компьютером стал болезненно переносить яркий свет (солнечный) и плохо видеть в полутьме.
Вот это — точно уже витаминов не хватает :) «Куриная слепота», скорее всего. Хотя, возможно, недостаточное сужение зрачка. Глаза при ярком свете с узким зрачком или широким?
Всё очень просто :D SSD на 16Гб сделаны ещё по старым технологиям и не такие быстрые. 32Гб из-за малой распространённости сегодня стоят _дороже_, чем на 64 :)
Я ориентируюсь сейчас конкретно на TS32GSSD25S-M (~7600руб) и TS64GSSD25S-M (~6200р.)
>Имхо, все необходимые куски системы вполне можно впихнуть в 4 гига (а то и меньше, смотря что и как пихать).
Ну, у меня на домашнем десктопе /usr сейчас 28Гб. И /opt на 2Гб.
>но забывать по /bin и /sbin, а также про /lib — считаю ошибкой =)
Угу, ты прав. Так что 32Гб мне не хватит ;)
>А вот /tmp вообще лучше всего в памяти развернуть, если позволяет.
4Гб позволяет ;) (точнее, 3,3Гб, ибо PAE и x86_64 меня пока не привлекают :)) И /var/tmp/portage там же.
Идея прекрасная :) Но фишка в том, что никакому приложению не нужно грузить по одной функции :D И функции они грузят целыми кодоблоками, в наше время на сотни килобайт порой, и ресурсы грузят мегабайтами.
Да, наверное, на машине с 512Мб и Вистой, сожравшей все эти 512Мб, реально получить выигрышь в несколько процентов, что и показывает тест Tom's Hardware, но как только в дело вступает банальная предварительная выборка, никакого выигрыша флешка уже не даст.
>Да, для SSD-накопителя ReadyBoost особой разницы не даст
Да, вообще не даст, а вчистую продует _в любых_ условиях :) Время доступа у SSD меньше, скорость чтения — НАМНОГО выше.
>Впрочем, людям, у которых есть prelink и Gentoo, ReadyBoost не нужен.
prelink — несколько не то. А так — я планирую взять себе SSD гигабайта на 64, как только цены упадут до ~$150. Закинуть туда /opt со /usr и опаньки :) Благо, в Linux очень легко отделить части системы друг от друга.
А на 1Гб говорить о хоть каких-то измерениях вообще смешно: www.tomshardware.com/reviews/windows-vista-superfetch-and-readyboostanalyzed,1532-5.html
А тут на форуме у людей Фотошоп с 8 секунд за 4 запускаться начинает. Идите сообщите Том'c Хардваре, что у них результаты не отражают действительность :)
…
Чего только сила самовнушения не творит! :)
А проецироваться она будет через астрал? :)
Нет, через те же запросы чтения. И как закажет приложение хотя бы иконку одну хайрезную на 50кБ — всё, уже флешка уступает. Закажет десяток иконок подряд из одного ресурса — не просто уступает, а прямо пролетает :)
…
Ну поставь ты портейбл версию того же Firefox на флешку и на HDD и сравни время запуска. И вопросы тут же отпадут :)
Для HDD это десяток перемещений/поисков по 6мс, т.е. 60мс + десяток чтений, т.е. 5Мб при скорость 50Мб/с — 0.1 сек. Итого, 0.16 сек. Те же самые 12.5 раз, пропорции не изменятся, т.к. в предыдущем расчёте считался полный цикл.
Кстати, если файлы будут больше размером, то разрыв начнёт увеличиваться. Если меньше — уменьшаться. Можно посчитать, с какого размера. Но тут надо учесть собственную латентность USB-флешек, это около 1мс. Тогда скорость доступа к файлам сравняется на размере S = Sf*Sh*(Ah-Af)/(Sh-Sf) = 50e6*2,5e6*(6e-3-1e-3)/(50e6-2,5e6) = 12,8кБ. Т.е. если размеры файла менее 15кБ, то флешка быстрее. Увы, размер это совершенно для системных файлов нехарактерный.
…
Правда, я тут упустил сперва, что речь идёт про ноутбучные HDD. У них время доступа похуже, бывает до 12мс. Тогда «равноскоростной» размер файла будет 28,2кБ. Но погоды это почти не сделает, всё лимитирует скорость чтения…
…
На самом деле, я наступал на эти грабли лет 8 назад. Мне как-то нахаляву попали 2 стареньких гигабайтных SCSI-диска. Старенькие, но SCSI же! :) И я их соединил в софтверный рейд. Время доступа по тем временам совсем какое-то смешное получилось. Всё это затеял я для того, чтобы туда своп кинуть. Как же я удивился, когда вместо ускорения система начала очень и очень ощутимо тормозить :) Небольшое исследование тут же показало, что всё упирается не во время доступа, а в скорость чтения…
Вставил флешку и набрал swapon /dev/sdd1 (или куда оно там подцепится).
…
Но это безумие — делать своп на флешке :D
Сейчас, правда, ни тот, ни другой формат записи с таковыми не работают.
Или же Вы хотели сказать что-то другое?
Вот сравнение самого быстрого метода со ссылки и preg_match:
test_strrchr: 3.47257399559
test_preg_match: 1.57902884483
Почувствуйте разницу :)
Если же речь идёт просто об извлечении, то:
test_strrchr: 3.38620686531
test_preg_match: 2.8885819912
Даже чтобы извлечь последние символы после ".", preg_match работает быстрее :) Кроме того, он отловит и отсутствие расширения…
short_open_tag || «1» || PHP_INI_PERDIR || PHP_INI_ALL в PHP <= 4.0.0.
Т.е. сработает в 3.xx или 4.0.0 только :)
substr: time=1.58525490761
preg_match: time=1.44538593292
array: time=1.14502310753
И, наконец, цепочки символов (задача — проверить расширение файла):
substr: time=1.64853310585
preg_match: time=1.44550204277
(массив тут уже непригоден).
substr: time=1.13405108452
preg_match: time=1.37561202049
array: time=0.460075139999
У компьютерщика, м.б., и больше :)
В обычных условиях — немного поменьше. Вроде, процентов 85. Там ещё слух процентов 10 на себя берёт.
Но всё равно — много :)
Тогда это не куриная слепота. А что-то с мышцами, отвечающими за диафрагменность зрачка. Тут моих общих знаний не хватит, я б рекомендовал к врачу обратиться. Витамины, боюсь, не особо помогут.
Всё нравится :) Я говорю, что мою идеологию можно реализовать на любом языке с развитой рефлексией. Сейчас использую PHP. Столь же легко сделать на Python или Ruby, Perl. Немного подумав, можно и на Java :) Чем и планирую заняться как будет время и желание…
>читать если нужно напишу подробней
Пробежал пока очень бегло. У меня используется что-то среднее… Пример GET/POST обработчика actions: hg.balancer.ru/hgwebdir/bors-core/file/6a98c39d7867/inc/bors/form_save.php (19-я, 139-я строки).
Кстати, небольшой хинт: if(substr($str,0,1)=='_') работает _намного_ медленнее, чем if(preg_match('/^_/', $str)) :) Видимо, вся фишка в экономии на создании временной строки. Я когда-то Smarty так ускорил раз в 5, подменив массу substr или {} на соответствующие preg_*, особенно, когда после сравнения требовалось ещё и подстроки извлекать. Правда, было это во времена ~2.6.14. Патчи мои не приняли без комментариев, повторно уже не связывался :)
ob_start();
Простого (и более быстрого, чем с перехватом) способа, ИМХО, не будет. Можно запретить в шаблоне любой вывод, сразу начинать его с "<?php..." и отказаться от всех echo в пользу $RESULT.="..."
:)
Кроме того, в моём случае можно написать обработчик не уровня рендерера тела страницы, а уровня генератора страницы в целом. Но тогда проще уже сделать шаг дальше и тупо писать отдельный PHP-скрипт, который и будет выводить всё сам (пусть и пользуясь для извлечения данных функционалом фреймворка).
>наскидку вижу что логика очень прозрачная
Это было одной из целей.
>это плюс, но много сущностей плодите
Есть такое, это обратная сторона микроядерности, модульности и многофункциональности. Компенсируется тем, что сущности все простые и унифицированные :)
Фактически, этот фреймворк — не столько набор кода, сколько набор правил и соглашений. Поэтому, когда придёт надобность, смогу быстро реализовать его на любом языке с развитой рефлексией (в ближайших планах Java, но не в области Web'а).
Собственно, вот весь код рендерера: hg.balancer.ru/hgwebdir/bors-core/file/6a98c39d7867/classes/render/php.php
А вот — пример шаблона: hg.balancer.ru/hgwebdir/bors-airbase/file/30143ac88174/classes/bors/airbase/board/show/latest.tpl.php
Класс-источник данных для шаблона: hg.balancer.ru/hgwebdir/bors-airbase/file/30143ac88174/classes/bors/airbase/board/show/latest.php
И, собственно, результат работы: forums.airbase.ru/forum/latest/
(хотя фишка пока чисто экспериментальная, всё остальное — на Smarty)
Я очки не снимая 20 лет ношу — не изменилось ни на 1/10 диоптрии с тех пор :)
Вот это — точно уже витаминов не хватает :) «Куриная слепота», скорее всего. Хотя, возможно, недостаточное сужение зрачка. Глаза при ярком свете с узким зрачком или широким?