I always romoving 'current' class of all siblings then add 'current' class to my clicked one. I want to know will it be faster only removing 'current' class of which has 'current'.seems to be a simple question, but I really want to know.
Yes, filtering the query to a smaller set of elements will perform faster, because there are less elements to check.
In modern browsers, jQuery will use native methods to query the DOM, so adding the selector has a negligible performance impact.
I don't think there's much difference, since there's only one "current". It doesn't matters too much for querying one more element or one less.
Usually I'll first find out the outer element to narrow down
$('#selectionDiv').find() ....
Depending on how many elements you are re-classing, the impact of the optimization will of course vary.
I tested it, http://jsperf.com/reclassing-all-or-one, using 7 (seemed reasonable for for example navigation tabs) divs and I think the difference was significant (reclassing all 30% slower than only one), percentage wise. If one cares about actual time though it may not be, but I can't really see any reason not do be distinct.
Related
Is it good to depend on the dom (CSS)hover, for detecting when i'm on another div, or figure that from the already stored array of all the div.s positions and dimensions on the page,
keep in mind that the said array, updates every time an element changes either position/dimension
i want the process to be effecient, a part of me want to depend on that array for detecting when i'm over another div. but i'm afraid that, that will be an extra processing.
can anybody please help me ?? (thanks in advance)
To my knowledge, relying on the DOM would be the more advantageous of the two. Like, arbitter said, relying on CSS will probably have a very slight performance advantage, but really this type of process wouldn't slow down your program all that much, if any.
I was wondering if there is any difference between .filter(':last') and .last()?
For me it looks like they're doing the same, but I'm new to jQuery. If there is no difference in the result, which one is recommended or is it just a matter of personal preference?
last works by saying "give me the last element from the selection". It takes just two function calls and four lines of code to do so. It can't be done in a quicker way.
filter(':last'), however, is much more complex. It is a much more flexible system, allowing multiple elements to be returned if that's what you want, or multiple conditions, or a mixture of both. It is much less efficient, because it has to work out what you want. For instance, parsing ':last' takes a little time, whereas with the last function it's a simple property lookup.
last is by far the more efficient.
:last - Selects the last matched element.
last() - Reduce the set of matched elements to the final one in the set.
As you can see, they do the same thing (in terms of the end result, anyway).
last() is slightly faster than :last (although you may not notice it, it's always good to know).
.filter(":last"), although making the best (performance-wise) out of :last, still involves more function calls and is still slower than last() - although it does have its advantages (see #lonesomeday's answer for those).
My recommendation however would be to generally use last() as opposed to the former.
I am appending large amounts of table row elements at a time and experiencing some major bottlenecks. At the moment I am using jQuery, but i'm open to a javascript based solution if it gets the job done.
I have the need to append anywhere from 0-100 table rows at a given time (it's actually potentially more, but I'll be paginating anything over 100).
Right now I am appending each table row individually to the dom...
loop {
..build html str...
$("#myTable").append(row);
}
Then I fade them all in at once
$("#myTable tr").fadeIn();
There are a couple things to consider here...
1) I am binding data to each individual table row, which is why i switched from a mass append to appending individual rows in the first place.
2) I really like the fade effect. Although not essential to the application I am very big on aesthetics and animations (that of course don't distract from the use of the application). There simply has to be a good way to apply a modest fade effect to larger amounts of data.
(edit)
3) A major reason for me approaching this in the smaller chunk/recursive way is I need to bind specific data to each row. Am I binding my data wrong? Is there a better way to keep track of this data than binding it to their respective tr?
Is it better to apply affects/dom manipulations in large chunks or smaller chunks in recursive functions?
Are there situations where the it's better to do one or the other? If so, what are the indicators for choosing the appropriate method?
Take a look at this post by John Resig, it explains the benefit of using DocumentFragments when doing large additions to the DOM.
A DocumentFragment is a container that you can add nodes to without actually altering the DOM in any way. When you are ready you add the entire fragment to the DOM and this places it's content into the DOM in a single operation.
Also, doing $("#myTable") on each iteration is really not recommended - do it once before the loop.
i suspect your performance problems are because you are modifying the DOM multiple times, in your loop.
Instead, try modifying it once after you get all your rows. Browsers are really good at innerHTML replaces. Try something like
$("#myTable").html("all the rows dom here");
note you might have to play with the exact selector to use, to get the dom in the correct place. But the main idea is use innerHTML, and use it as few times as possible.
Is there a significant difference if I construct a jQuery object around an element once or many times? For instance:
var jEl = $(el);
$.each(myArray, function() {
jEl.addClass(this);
}
versus:
$.each(myArray, function() {
$(el).addClass(this);
}
I know there are other ways to write this that might sidestep the issue, but my question is about whether I should work to do $(el) just once, or if it truly is irrelevant. The example is contrived.
Bonus points for explaining just what $(el) does behind the scenes.
I know that theoretically more work is being done, what I don't know is whether it matters... if jQuery caches it or the browsers are all really good at the second request or whatever, than its not worth it.
FYI: The relevant jQuery API link is here (which I provide because $() isn't the easiest thing to Google for): http://api.jquery.com/jQuery/#using-dom-elements
Also worth including this useful link: http://www.artzstudio.com/2009/04/jquery-performance-rules/, where several of his points center around saving, chaining, and selecting well.
Yes, there is a performance impact.
In the first example, only one instance is created.
In the second, an instance will be created for each iteration of the loop.
Depending on the size of myArray, that could lead to a lot of extraneous instances being created which will chew through memory.
The first way will be faster. First of all you are creating a new object each time also it will depend on your browser, your page and what el is.
If el is a string (for example "#myname") then $(el) will "query" the DOM to find that element. jQuery is quite fast in doing queries but it does take some time. So doing this many times will take that many times longer.
Do I get the bonus points?
Yes there will be. Each time $() is called, jQuery does a separate search of the DOM for the element.
If each search takes 0.1 seconds (usually much much faster, but it's an easy number to work with), and you've got 1000 elements in your array, that's 100 seconds devoted just to traversing the DOM in the second example, as opposed to just 0.1 seconds in the first.
Which of these is more efficient (i.e. faster):
$(elem).show();
or
$(elem).addClass(displayClass); // Where display class is "display: block;"
Or are they identical?
It depends what you're after, they do different things:
$(elem).show(); - shows the element, restoring the display from before .hide() or restoring the default display for the element type
$(elem).addClass(displayClass); - adds a class, always with a certain display, not really restoring what was there - this is less flexible
Which is faster? .addClass() hands down, you can test it yourself here, it simply does a lot less work than .show() does. However, it doesn't do as much feature-wise, so it's less flexible for the reasons above.
No, they are absolutely not identical.
There's a big difference between direct modifications to element styles and "indirect" modifications by changing the element's class, and that really should be pretty obvious. By writing cooperative code between Javascript and CSS, the class changes give you a lot more flexibility. The Javascript manages the state of elements, while the CSS drives the actual effect of that state.
The show() and hide() methods are handy and easy, but (in my opinion) managing state/appearance by class name is really a much more powerful and maintainable way to do things. In fact you can always write your own little jQuery plugins to add/remove classes that are meaningful to your app, to avoid having the class names themselves propagate through your code.
They're not identical; they work completely differently. They may in your case have the same effect, but don't count on it.
For example, addClass may not actually make the element visible in all cases. If the element has other styles which supercede the class (eg ID-level CSS, or inline styles, etc), then adding a class won't have any effect at all.
Also, setting display:block is only correct for elements that you want to be displayed as a block. If you've got inline elements (or worse, tables) and you try to display them as block, the results will probably not be what you're expecting.
Finally, .addClass() definitely involves more processing for the browser than .show(), so you're not making things any easier for your site by using it.
In short, if that's all you're trying to achieve, use .show() - it's the correct jQuery way to do it.