странно видеть +9 на коментарии о «поиск продолжается с места предыдущего найденного результата». в данном примере регулярка без /g и соответственно, сколько бы раз exec этой регулярки ни вызывали, он будет делать поиск с начала.
а по поводу этой оптимизации: на допотопных движках выигрышь будет существенный, на современных его нет. выигрышь тут в том что js не будет искать по строке есть ли у него уже такая регулярка. а проигрышь в том что надо будет доставать регулярку из следующего скопа в стеке скопов. в принципе и то и другое это 1 поиск в каком-то хеше.
глюки в каких-то реализациях трудно назвать «условиями». но в любом случае автор книги ошибся, а автор этой статьи слишком сильно углубляется в исследования delete, имхо.
Не понятно зачем автор перевел название Firebug и зачем нагородил столько непонятных объяснений вместо фразы «по стандарту переменные удалять нельзя»?!
Какая-то очень странная статья. Все браузеры кидают эксепшен при обращении к несуществующим переменным, а не только Опера.
Чтобы не было ошибок надо обращаться через window потому что это будет lookup свойств объекта а не резолв переменной. А если обращений к глобальным переменным много из какой-то функции, то для лучшей производительности лучше сделать локальную переменную для window.
Да и вообще как бы ни были быстры вызовы функций делать функцию для проверки на undefined это плохо…
Помоему тут автор просто переделал анонимные коллбеки в обычные (именованные) функции. Код стал чуть просторнее и чуть более редактируемым, но выяснить что после чего выполняется стало сложнее, имхо.
Помоему для таких задач можно использовать разного рода Lazy вычисления (типа Deferred из jQuery). Код при этом будет выглядить намного приятнее.
В IE8-9 и правда есть XDomainRequest, но там не все так хорошо как кажется. Во первых нельзя передавать свои хедеры, вообще. во вторых они даже Content-Type посчитали несекьюрным, так что на серверную сторону запросы приходят без него и приходится rewriterul'ами его добавлять чтобы серверная сторона начала распарссивать форму в пост данных. С http referer тоже проблемы. Так что пока IE не реализует level2 вокруг него еще плясать и плясать с бубном…
я уже давно смотрю в сторону посгтреса, он намного ближе к стандартам чем mysql. на mysql как-то не получается сделать все что хочется… хотя может я хочу слишком много… :)
SELECT SQL_NO_CACHE n.id,n.date,n2.title,c.id,c.date,c.body
FROM (
SELECT id,date
FROM news
ORDER BY date DESC
LIMIT 10
) as n
JOIN news as n2
ON n2.id=n.id
JOIN comment as c
ON c.news_id=n.id
AND c.date >= IFNULL((
SELECT c1.date
FROM comment as c1
WHERE c1.news_id=n.id
ORDER BY c1.date DESC
LIMIT 10,1
),«0/0/0»)
ORDER BY n.date DESC,c.date DESC;
я поднял количество тестовых записей в комментах до 1000 и мой первый запрос перестал работать :)
видимо он там все таки проходится в порядке индекса а не ордера и сооцно @cnt считает не в правильном порядке
второй запрос работает в 2.5 раза медленнее (78 против 31) зато правильно
а та то что ты написал с c.id in (...) мне mysql выдал «This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'»
походу даже в 6-ой версии этого еще нету (http://dev.mysql.com/doc/refman/6.0/en/subquery-errors.html)
SELECT *
FROM (
SELECT id,date,title
FROM news
ORDER BY date
LIMIT 10
) as n
JOIN comment as c
ON c.news_id=n.id
JOIN comment as c2
ON c2.news_id=n.id
AND c2.date >= c.date
GROUP BY n.id,c.id
HAVING COUNT(c2.id) <= 10
ORDER BY n.date DESC,c.date DESC
SET @old=0;
SET @cnt=0;
SELECT *
FROM (
SELECT id,date,title
FROM news
ORDER BY date
LIMIT 10
) as n
JOIN comment as c
ON c.news_id=n.id
WHERE (@cnt:=(if(n.id=@old,@cnt,n.id-(@old:=n.id)))+1)<=11
ORDER BY n.date,c.date DESC;
Я программирую на javascript’е не меньше чем на пхп и в нем есть много сахара, который позволяет программировать так, как мне хочется, а не думать надо ли мне это или можно обойтись аскетизмом чистого С.
По поводу explode, если это была подсказка то она была мне, а не SergeyKish :) В случае числовых индексов, соответствующих позициям элементов, мы можем сделать array_slice и потом присвоить в list. В остальных случаях без переменной не обойтись. Хорошо ли это? Я думаю что нет…
Вообще, мое глубокой убеждение что чем больше сахара тем лучше. Единственное что надо следить, чтобы весь сахар был в едином стиле и чтобы не плодились лишние символы, которые используются всего несколько раз.
Недавно видел видео с какой-то конференции где одному из девелоперов пхп был задан вопрос когда мы сможем при вызове вызове функции, возвращающей массив, сразу писать квадратные скобки без необходимости сохранять этот массив в переменную. На что этот девелопер ответил «А оно вам надо?!»
Так что, имхо, пхп идет в абсолютно непонятное «светлое будущее» и 6-ая версия будет переломной точкой, когда много людей его покинут…
а по поводу этой оптимизации: на допотопных движках выигрышь будет существенный, на современных его нет. выигрышь тут в том что js не будет искать по строке есть ли у него уже такая регулярка. а проигрышь в том что надо будет доставать регулярку из следующего скопа в стеке скопов. в принципе и то и другое это 1 поиск в каком-то хеше.
Чтобы не было ошибок надо обращаться через window потому что это будет lookup свойств объекта а не резолв переменной. А если обращений к глобальным переменным много из какой-то функции, то для лучшей производительности лучше сделать локальную переменную для window.
Да и вообще как бы ни были быстры вызовы функций делать функцию для проверки на undefined это плохо…
Помоему для таких задач можно использовать разного рода Lazy вычисления (типа Deferred из jQuery). Код при этом будет выглядить намного приятнее.
[«1»,«2»,«3»].map(function(value) {return parseInt(value)})
лучше написать
[«1»,«2»,«3»].map(Math.floor)
SELECT SQL_NO_CACHE n.id,n.date,n2.title,c.id,c.date,c.body
FROM (
SELECT id,date
FROM news
ORDER BY date DESC
LIMIT 10
) as n
JOIN news as n2
ON n2.id=n.id
JOIN comment as c
ON c.news_id=n.id
AND c.date >= IFNULL((
SELECT c1.date
FROM comment as c1
WHERE c1.news_id=n.id
ORDER BY c1.date DESC
LIMIT 10,1
),«0/0/0»)
ORDER BY n.date DESC,c.date DESC;
видимо он там все таки проходится в порядке индекса а не ордера и сооцно @cnt считает не в правильном порядке
второй запрос работает в 2.5 раза медленнее (78 против 31) зато правильно
а та то что ты написал с c.id in (...) мне mysql выдал «This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'»
походу даже в 6-ой версии этого еще нету (http://dev.mysql.com/doc/refman/6.0/en/subquery-errors.html)
SELECT *
FROM (
SELECT id,date,title
FROM news
ORDER BY date
LIMIT 10
) as n
JOIN comment as c
ON c.news_id=n.id
JOIN comment as c2
ON c2.news_id=n.id
AND c2.date >= c.date
GROUP BY n.id,c.id
HAVING COUNT(c2.id) <= 10
ORDER BY n.date DESC,c.date DESC
но роли это не играет…
я проверил у себя на:
CREATE TABLE `news` (
`id` int(11) NOT NULL auto_increment,
`date` datetime NOT NULL,
`title` varchar(200) NOT NULL,
PRIMARY KEY (`id`),
KEY `date` (`date`,`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `comment` (
`id` int(11) NOT NULL auto_increment,
`news_id` int(11) NOT NULL,
`date` datetime NOT NULL,
`body` varchar(200) NOT NULL,
PRIMARY KEY (`id`),
KEY `news` (`news_id`,`date`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
все работает
вот только 1-цы в @cnt куда-то теряется поэтому проверка на <=11 а не <=10
SET @cnt=0;
SELECT *
FROM (
SELECT id,date,title
FROM news
ORDER BY date
LIMIT 10
) as n
JOIN comment as c
ON c.news_id=n.id
WHERE (@cnt:=(if(n.id=@old,@cnt,n.id-(@old:=n.id)))+1)<=11
ORDER BY n.date,c.date DESC;
По поводу explode, если это была подсказка то она была мне, а не SergeyKish :) В случае числовых индексов, соответствующих позициям элементов, мы можем сделать array_slice и потом присвоить в list. В остальных случаях без переменной не обойтись. Хорошо ли это? Я думаю что нет…
Вообще, мое глубокой убеждение что чем больше сахара тем лучше. Единственное что надо следить, чтобы весь сахар был в едином стиле и чтобы не плодились лишние символы, которые используются всего несколько раз.
Так что, имхо, пхп идет в абсолютно непонятное «светлое будущее» и 6-ая версия будет переломной точкой, когда много людей его покинут…