jQuery UI Widget Selectors

Widgets in jQuery UI have their own selectors.  These selectors allow the developer to select widgets by type.  For example, if you want to select all progressbar widgets, you can do this.  The selector for a specific widget type is similar to other element selectors you'd use with jQuery.  For example, you can say :button to retrieve button elements.  This same approach is used with jQuery widgets.

Each widget selector is constructed and added to the core jQuery set of expressions.  It does so by taking the name space, in this case, ui, and combining it with the widget name.  So we can make queries such as :ui-tabs or :ui-progressbar.  This is a great approach - we know that we're only retrieving elements that are real jQuery UI widgets.  There is a problem though.  It's slow and can't be used universally throughout all jQuery UI has to offer.

For example, I used the following to benchmark the widget type selector:

var iterations = 100;
var start = new Date().getTime();
for (i = 0; i < iterations; i++) {
    $(':ui-tabs');
}
var end = new Date().getTime();
console.log(end - start);

Notice we're using the : character in the selector - this invokes the selector built by the base widget.  However, to get a feel for how relatively slow this operation is, try replacing the : with . so you end up with $('.ui-tabs').  Notice the performance difference?  So why would anyone in their right mind use this widget selector?

The rationale behind such a selector is that you should be able to select all widget types base on, well, their type.  Think of a class method in Python or Java that will return all instances of that class.  It's an intuitive leap to transform "get me all accordion widgets" into :ui-accordion.  This way, it becomes a standard query format for widgets - namespace (ui) and widget name.

So what is wrong with using the class selector variant to retrieve all widgets belonging to a specific class?  Nothing aside from the fact that we can't be absolutely certain of widget class names.  For instance, if another UI developer on your team were to build a widget, and you now write some code that wants to grab them all.  You'd have to know ahead of time, or do some investigation work, to figure out which class is applied to every widget of that type.  Well, not necessarily.

You'll notice that you can use the class-based variant of the above query to retrieve all widgets of a specific type for every jQuery UI widget.  For example, .ui-tabs, .ui-progressbar, .ui-button, all these queries work fine and they're much faster than the widget selector that automatically extends the UI core for every widget - .ui-tabs is much faster than :ui-tabs.

You'll also notice that the naming in CSS classes applied to the widgets are all consistent.  This CSS class naming schema doesn't only have a role with themes - we can use this consistent convention to actually speed-up our code.

Memory Management

There is a new approach to memory management that claims to be able to speed up applications. Actually, it has the potential to but nothing is carved in stone. It would be interesting to contrast the performance gained versus the stability lost after implementing this method.

Python Benchmarks

With new-style Python classes, one can help cut down on the memory cost associated with creating new instances. This is down by using the __slots__ class attribute. When the __slots__ attribute is used in the declaration of new-style classes, the __dict__ attribute is not created with instances of the class. The creation of the __dict__ attribute can be expensive in terms of memory when creating large numbers of instances. So, the questions that begs itself is why not use the __slots__ attribute for all classes throughout an application? The simple answer is, because of the lack of flexibility offered by attributes that live inside memory that has been pre-allocated by a slot. The other problem with using the __slots__ attribute for every class is the burden involved with maintaining all the slots, in all the classes. These could be in the several hundred range or more. So, this simply isn't feasible.

What is feasible, however, is to define __slots__ attributes for smaller classes with few attributes. Another factor to consider is instantiation density of these classes. That is, the __slots__ attribute is more beneficial with large numbers of instances because of the net memory savings involved. Consider the following example.

#Example; Using __slots__

import timeit

#A simple person class that defines slots.
class SlottedPerson(object):
  __slots__=("first_name", "last_name")

  def __init__(self, first_name="", last_name=""):
      self.first_name=first_name
      self.last_name=last_name
    
#A simple person class without slots.
class Person(object):
  def __init__(self, first_name="", last_name=""):
      self.first_name=first_name
      self.last_name=last_name

#Simple test for the slotted instances.
def time_slotted():
  person_obj=SlottedPerson(first_name="First Name", last_name="Last Name")
  first_name=person_obj.first_name
  last_name=person_obj.last_name

#Simple test for the non-slotted instances.
def time_non_slotted():
  person_obj=Person(first_name="First Name", last_name="Last Name")
  first_name=person_obj.first_name
  last_name=person_obj.last_name

#Main
if __name__=="__main__":
  #Initialize the timers.
  slotted_timer=timeit.Timer("time_slotted()",\
                             "from __main__ import time_slotted")
  non_slotted_timer=timeit.Timer("time_non_slotted()",\
                                 "from __main__ import time_non_slotted")

  #Display the results.
  print "SLOTTED    ",slotted_timer.timeit()
  print "NON-SLOTTED",non_slotted_timer.timeit()

In this example, we have two very simple classes. The SlottedPerson and the Person classes are identical except for the fact that the SlottedPerson class will always outperform Person. This is because there are always going to be performance gains when the interpreter doesn't need to allocate memory.

Stand Alone Python Servers

The Python programming language provides a full-featured suite of both high and low-level networking capabilities. This allows for stand-alone web servers to be written in Python. For instance, CherryPy is an object publishing framework for Python with a very powerful built-in HTTP server.

In production environments, Python is often run behind a more production-ready web server such as Apache. The main reason for doing so is performance. Web servers such as Apache are written low-level languages and thus have a raw computing advantage. They are generally mature as software packages. The have been tried and tested for much longer than most Python web servers.

Another reason may be architecture. If there are several other production services that already use Apache, then it would make sense for consistency. It is much easier to maintain a single web server than many, often very different web servers.

If one were to deploy a single Python web application with a single web server, is deploying to a production-ready HTTP server really necessary? Are the performance gains really all that noticeable in the grand end-user scheme of things? As for stability, this is the kind of thing that should be rigorously tested before even considering placing the stable label on the server to begin with.

jQuery Context

How many times have you wished there was an easier way to find DOM elements in a given HTML document? The jQuery javascript toolkit offers a powerful set of CSS selectors that enable developers to do just that; easily query DOM elements. The heart of the jQuery toolkit relies on these selectors. If you are using jQuery in your javascript applications to manipulate the DOM tree, you probably haven't noticed any performance issues while issuing queries. This is because jQuery is highly optimized.

However, the performance can still be improved. The jQuery() function is most often used to query the entire DOM tree. That is, if you issue a query for a DOM id, the selector is applied to every element in the document. More often than not, there is an opportunity to specify a context. For instance, when issuing a query, the developer may know that the given id exists somewhere within another element. Luckily, this element can be specified as a query context when issuing the query.

The benefit to using the context parameter is that the search for the specified DOM elements is narrowed. Possibly by a significant margin. There is another benefit to using the context parameter. Maintainability. Developers can easily deduce why a given query isn't yielding expected results for instance. Finally, the context can be used pragmatically to affect behavior. Below is an example of how to apply the context parameter to DOM queries using the core jQuery() function.

//Example; jQuery context.

var my_div=jQuery("#my_div");
var my_elements=jQuery(".my_elements", my_div);