<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Finding Element&#160;Positions</title>
	<atom:link href="http://particletree.com/notebook/finding-element-positions/feed/" rel="self" type="application/rss+xml" />
	<link>http://particletree.com/notebook/finding-element-positions/</link>
	<description>Everyone needs a hug.</description>
	<pubDate>Wed, 19 Nov 2008 12:08:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Altay Guvench</title>
		<link>http://particletree.com/notebook/finding-element-positions/#comment-22080</link>
		<dc:creator>Altay Guvench</dc:creator>
		<pubDate>Tue, 14 Aug 2007 01:49:26 +0000</pubDate>
		<guid isPermaLink="false">http://particletree.com/notebook/finding-element-positions/#comment-22080</guid>
		<description>&lt;p&gt;Hey Ryan, I'm joining the discussion a little late, but this seemed worth pointing out.  Don't the hasClassName and previousSiblings methods call Element.extend on the node?  Apparently, that's a LOT slower in IE than other browsers, and the source of a many IE/Prototype bottlenecks:  http://groups.google.com/group/prototype-core/browse_thread/thread/aecbf8e008782d6a&lt;/p&gt;

&lt;p&gt;It seriously adds up over 800 iterations.  I love prototype as much as the next guy, but try a vanilla comparison in your loop (e.g. if (elt.className=='target') ...).  Not only will this be faster in all browsers but -- most importantly -- IE does it almost as fast as Firefox!&lt;/p&gt;

&lt;p&gt;If you wanted to be a little fancier, maybe you could do $('lis').getElementsByTagName('li'), and extend ONLY the resulting array -- rather than every single node in the array.  Then you can use prototype's Array.indexOf method.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hey Ryan, I&#8217;m joining the discussion a little late, but this seemed worth pointing out.  Don&#8217;t the hasClassName and previousSiblings methods call Element.extend on the node?  Apparently, that&#8217;s a LOT slower in IE than other browsers, and the source of a many IE/Prototype bottlenecks:  <a href="http://groups.google.com/group/prototype-core/browse_thread/thread/aecbf8e008782d6a" rel="nofollow">http://groups.google.com/group/prototype-core/browse_thread/thread/aecbf8e008782d6a</a></p>

<p>It seriously adds up over 800 iterations.  I love prototype as much as the next guy, but try a vanilla comparison in your loop (e.g. if (elt.className==&#8217;target&#8217;) &#8230;).  Not only will this be faster in all browsers but &#8212; most importantly &#8212; IE does it almost as fast as Firefox!</p>

<p>If you wanted to be a little fancier, maybe you could do $(&#8216;lis&#8217;).getElementsByTagName(&#8216;li&#8217;), and extend ONLY the resulting array &#8212; rather than every single node in the array.  Then you can use prototype&#8217;s Array.indexOf method.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Campbell</title>
		<link>http://particletree.com/notebook/finding-element-positions/#comment-21964</link>
		<dc:creator>Ryan Campbell</dc:creator>
		<pubDate>Fri, 27 Jul 2007 02:30:51 +0000</pubDate>
		<guid isPermaLink="false">http://particletree.com/notebook/finding-element-positions/#comment-21964</guid>
		<description>&lt;p&gt;The test was actually run with the target being #800. I haven't done any official testing, but I believe that previous siblings is always faster.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>The test was actually run with the target being #800. I haven&#8217;t done any official testing, but I believe that previous siblings is always faster.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Soto</title>
		<link>http://particletree.com/notebook/finding-element-positions/#comment-21963</link>
		<dc:creator>Alex Soto</dc:creator>
		<pubDate>Fri, 27 Jul 2007 00:54:00 +0000</pubDate>
		<guid isPermaLink="false">http://particletree.com/notebook/finding-element-positions/#comment-21963</guid>
		<description>&lt;p&gt;It would be interesting to see if it makes a difference where the target is in the list.  Would the previous siblings be slower if the target element was at the end of the list (#800) as opposed to early in the list?&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>It would be interesting to see if it makes a difference where the target is in the list.  Would the previous siblings be slower if the target element was at the end of the list (#800) as opposed to early in the list?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Campbell</title>
		<link>http://particletree.com/notebook/finding-element-positions/#comment-21960</link>
		<dc:creator>Ryan Campbell</dc:creator>
		<pubDate>Thu, 26 Jul 2007 14:04:45 +0000</pubDate>
		<guid isPermaLink="false">http://particletree.com/notebook/finding-element-positions/#comment-21960</guid>
		<description>&lt;p&gt;The Firefox and Safari 3 tests were done on the same machine. Then, the Safari 3 test was redone on a Windows machine, and the speed was very similar. That machine then ran the IE tests. It might not be 100% accurate, but I would imagine IE6 is still much slower at these types of operations.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>The Firefox and Safari 3 tests were done on the same machine. Then, the Safari 3 test was redone on a Windows machine, and the speed was very similar. That machine then ran the IE tests. It might not be 100% accurate, but I would imagine IE6 is still much slower at these types of operations.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Colm</title>
		<link>http://particletree.com/notebook/finding-element-positions/#comment-21954</link>
		<dc:creator>Colm</dc:creator>
		<pubDate>Thu, 26 Jul 2007 08:34:00 +0000</pubDate>
		<guid isPermaLink="false">http://particletree.com/notebook/finding-element-positions/#comment-21954</guid>
		<description>&lt;p&gt;What tool did you use to test the time?&lt;/p&gt;

&lt;p&gt;Also wouldn't the spec's of the machines (memory, processor) dictate the speed?&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>What tool did you use to test the time?</p>

<p>Also wouldn&#8217;t the spec&#8217;s of the machines (memory, processor) dictate the speed?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: AsiaPartTime</title>
		<link>http://particletree.com/notebook/finding-element-positions/#comment-21952</link>
		<dc:creator>AsiaPartTime</dc:creator>
		<pubDate>Wed, 25 Jul 2007 23:57:38 +0000</pubDate>
		<guid isPermaLink="false">http://particletree.com/notebook/finding-element-positions/#comment-21952</guid>
		<description>&lt;p&gt;Good guide for me to loop list. but my company don't allow to use Prototype librayr :(&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Good guide for me to loop list. but my company don&#8217;t allow to use Prototype librayr :(</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Campbell</title>
		<link>http://particletree.com/notebook/finding-element-positions/#comment-21950</link>
		<dc:creator>Ryan Campbell</dc:creator>
		<pubDate>Wed, 25 Jul 2007 17:14:39 +0000</pubDate>
		<guid isPermaLink="false">http://particletree.com/notebook/finding-element-positions/#comment-21950</guid>
		<description>&lt;p&gt;They were done with version 1.5.1.1.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>They were done with version 1.5.1.1.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew Dupont</title>
		<link>http://particletree.com/notebook/finding-element-positions/#comment-21949</link>
		<dc:creator>Andrew Dupont</dc:creator>
		<pubDate>Wed, 25 Jul 2007 16:58:39 +0000</pubDate>
		<guid isPermaLink="false">http://particletree.com/notebook/finding-element-positions/#comment-21949</guid>
		<description>&lt;p&gt;Those benchmarks suggest to me that we haven't fully optimized methods like &lt;code&gt;previousSiblings&lt;/code&gt;. Such methods take an optional CSS-selector argument to filter with, but when the argument is omitted there shouldn't be a Selector query at all. (Were these benchmarks using the latest version of Prototype?)&lt;/p&gt;

&lt;p&gt;Maybe IE is just really slow with this sort of task â€” your other approaches yield nearly identical results â€” but when I see such a disparity between IE and Firefox/Safari I immediately suspect a Selector query. I'll look into this.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Those benchmarks suggest to me that we haven&#8217;t fully optimized methods like <code>previousSiblings</code>. Such methods take an optional CSS-selector argument to filter with, but when the argument is omitted there shouldn&#8217;t be a Selector query at all. (Were these benchmarks using the latest version of Prototype?)</p>

<p>Maybe IE is just really slow with this sort of task â€” your other approaches yield nearly identical results â€” but when I see such a disparity between IE and Firefox/Safari I immediately suspect a Selector query. I&#8217;ll look into this.</p>]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.244 seconds -->
