Небольшой класс для работы с сериализированными данными

А читал очень невнимательно и поверхностно. Читал бы менее поверхностно и более вдумчиво, да еще бы и с комментами, обратил бы внимание на то, что:

1) Во главу угла надо ставить удобство.
2) Чтобы добиться более-менее заметных при получении замеров расхождений, которые нельзя было бы списать на погрешность/просаживание процессора по левой причине, там использовались "конфиги" с сотнями и тысячами строк-параметров.
3) Конфиг парсится один раз. Хочется мегапроизводительности - составь конфиг из инструкций, пишущих его в шаредмемори. Но конфиг - это не тонкое место. Это разовая операция. Она всегда 100% предсказуема в плане потребления ресурсов. Никогда не просядет. Не породит утечки. Не имеет алгоритма, который можно отрефакторить. Это не то место, где стоит экономить микросекунды и килобайтики.

По сути это статья про то, какой конь в вакууме быстрее летает, сферический или додекаэдрический. Оказалось, что сферический конь в вакууме действительно достигает точки назначения на 0.002 секунды быстрее. В реальных же условиях, на Земле, это не несет особой практической ценности.

Удобство конфига для человека - это не просто блажь. Тривиальная ситуация - выгрузил проект с локалки на внешку, и все перестало работать, потому что:
1) хоумдиректори левое.
2) данные для бд левые.
3) основной домен левый.
4) прочие левые данные, специфичные для сервера.

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

З.Ы. За старания - пять. Может для кого-то и будет полезным, кто знает.

 

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

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

 

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

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

 

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

 

просто подход очень для кеша подходящий =)
а про конфиг вроде обмусолили уже.

 

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

 

ну про отладочное речь не идёт. там что угодно можно делать.

вот мои кешеры. на файлах быстрее, чем через мемкеш, но надо самому следить за переполнением.

мемкеш:

Код (PHP):

1. <?php
2.  
3. class Cache
4. {
5.  
6.   private static $mc = null;
7.  
8.   private static function Init() {
9.     self::$mc = new Memcache();
10.     foreach (CFG::$pincms['cache']['servers'] as $server) {
11.       self::$mc->addServer($server['host'], $server['port']);
12.     }
13.     return true;
14.   }
15.  
16.   public static function Get($hash) {
17.     if (is_null(self::$mc)) {
18.       if (self::Init() == false) {
19.         return false;
20.       }
21.     }
22.     // debug mode
23.     //    $r = self::$mc->get($hash);
24.     //    return $r;
25.     return self::$mc->get($hash);
26.   }
27.  
28.   public static function Set($hash, $content) {
29.     if (is_null(self::$mc)) {
30.       if (self::Init() == false) {
31.         return false;
32.       }
33.     }
34.     return self::$mc->set($hash, $content);
35.   }
36.  
37. } 

на файликах:

Код (PHP):

1. <?php
2.  
3. class Cache {
4.   private static $path = '';
5.   private static $ok = false;
6.  
7.   public static function Init() {
8.     if (self::$ok === true) {
9.       return true;
10.     }
11.     PinCMS::$binhash = false;
12.     self::$path = ROOT . DS . 'filecache' . DS;
13.     if (!is_dir(self::$path)) {
14.       mkdir(self::$path);
15.     }
16.     if (touch(self::$path . 'test')) {
17.       self::$ok = true;
18.     }
19.     self::$ok = true;
20.     return self::$ok;
21.   }
22.  
23.   public static function Get($hash) {
24.     if (!self::Init()) {
25.       return false;
26.     }
27.     $fp = self::$path . $hash;
28.     if (!file_exists($fp)) {
29.       return false;
30.     }
31.     $content = file_get_contents(self::$path . $hash);
32.     if ($content === false) {
33.       return false;
34.     }
35.     return unserialize($content);
36.   }
37.  
38.   public static function Set($hash, $content) {
39.     if (!self::Init()) {
40.       return false;
41.     }
42.     $fp = self::$path . $hash;
43.     if (!touch($fp)) {
44.       return false;
45.     }
46.     $content = serialize($content);
47.     return file_put_contents(self::$path . $hash, $content);
48.   }
49.  
50. }
51.  
52. Cache::Init(); 

 

У меня подключаемые компоненты используют метафайлы с уровнем вложенности больше 1. Например секция настроек, состоящая из подсекций, состоящих из подсекций, в зависимости от типа параметра. Но я для себя выбрал не YAML, а XML. Личное предпочтение.

А вот для конфига системы в целом, вложенность имеет сомнительную ценность.

 

она реализована до них, поэтому я не делал ничего такого.

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

реализовано до кешера, опять же.

может быть. в текущих условиях не требуется.

походу дебаговая строка, которую я тупо забыл убрать. благодарствую.

дык и не надо.