Структура данных для поиска подходящих CSS-правил

Если ссылку дашь, то посмотрю обязательно. Я даже css парсера никак найти в исходниках (chrome) не мог.

Структура данных для поиска подходящих CSS-правил

(1ый абзац): Проверять каждое правило для каждого элемента — это неправильно (медленно).
(2ой абзац): Вопрос именно в эффективном поиске элемента (множества эелементов), и это специфично именно для css, так как мы последовательно обходим все дерево html и для каждого элемента применяем правило.

Я пока что пришел к выводу что мне нужна инверсированная хеш-таблица (или что-то типа) правил, в которой селекторы описаны справа налево. К примеру:

div p.links a

превратится в (упрощенно): table[ 'a' ]['p.links']['div']

Путь я тоже буду инверсировать. Например 'html > div#content > p.links > a' превратится в 'a < p.links < div#content < html'.
Он будет выступать в качестве фильтра.
Т.е. читаю 'a' — беру из таблицы правила table['a'].
Читаю p.links — если есть правило, неподходящее под p.links (например table['a']['< .other'] — отфильтровываю его.
И т.д. до конца.
Если в таблице остались элементы с непройденными путями — отфильтровываю их.
Оставшиеся правила объединяю и возвращаю результат.

Пока что такой алгоритм. Может надумаю что-то получше.

Структура данных для поиска подходящих CSS-правил

Задал этот же вопрос на stackoverflow, но большой надежды что там ответят нету, ресурс сильно опопсел.

Как оптимизировать Sphinx indexer «sorted»?

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

Копирование большого объёма данных из одной таблицы в другую

>> А что вообще скажите, по поводу работы с таким большим объёмом данных?
Опишите задачу. Нужно знать как эти данные дальше используются. Мне, например, сложно представить, зачем 300млн копировать из одного места в другое, в котором в 100 раз меньше данных.
>> Ещё подскажите, что скажите по поводу следующего метода, он тут продуктивнее будет?
Протестируйте, но думаю что не будет. Большие расходы на создание и чтение файла (парсинг).

Копирование большого объёма данных из одной таблицы в другую

И еще, если таблицы одинаковые по структуре, то стоит попробовать сначала скопировать temp_pos в другую временную таблицу, потом во временную добавить записи из pos, удалить pos и переименовать временную таблицу в pos.
MySQL должен соптимизировать полное копирование табицы (insert into temp_pos_temp select * from temp_pos). Дальнейшая вставка 3млн должна пройти заметно быстрее.

Непонятки с правами GIT при выполнении хука?

а вы под каким пользователем делаете git push origin master? Там скорее всего до хука даже не доходит дело. Оно обновить ветку не может

Node.js для простых сайтов. Стоит ли забивать на PHP?

Вы про простые сайты спрашивали. Для простых нет смысла в чем-то другом кроме php. Для сложных проектов уже можно разрабатывать архитектуру, думать… расписывать бюджет :)
По поводу чата, вот: habrahabr.ru/post/79189/
Один из основных принципов программирования — KISS.
Для простого простое, для сложного сложное. Для простого сложное в основном java-программисты пишут, в виду специфики работы :)

Вывести значения объекта внутри объекта c помощью $.each?

$.each(plugins, function(idx, elem){
    $.each(elem, function(idx, e){
        document.write( e[ idx ] );
    });    
});

Вывести значения объекта внутри объекта c помощью $.each?

Ну так idx и есть тот самый ключ, или что вы имеете ввиду?

Вывести значения объекта внутри объекта c помощью $.each?

jsfiddle: http://jsfiddle.net/MKDUF/