Mozilla - Bookmarks' keywords & Quick Searches

This world is really full of amazing things. How much ever we discover and find out, there will be something interesting just right next to us which we would not have figured out. This post is about one such thing, which was right here from such a long time and I had not figured it out.

The first hints for this came to me when I saw one of my colleagues, Pramod S, at NI using shortforms for Google(g) and Wikipedia(wp) when searching. I thought he had come across some hack and tweaked his browser. But just today I realized that it is infact a feature in Firefox.

For any URL or webpage that we bookmark we can assign a keyword, a shortform, which can be entered in the URL bar to visit that bookmarked page. This is really a very useful things if we visit certain pages over and over again. In my case http://mxr.mozilla.org/seamonkey/ is one site that I cannot live without. So I have keywords for the 3 different searches available at this page, viz:

• mxrf - for file search(find)
• mxri - for identifier search
• mxrt - for free form text search

This feature is really handy and increases the brwosing speed to a great extent.

How to get this working? or how to assign the keywords?. This again is really simple. For existing bookmarks just go to the Bookmark properties by Right-Clicking on that and you get a small dialog with a text field for Keyword. Key in whatever you want and click on OK. Thats it you are ready to fire the internet with your keywords. For new bookmarks it is still easier. When you are creating a bookmard with the helper dialog you get the keyword field which you can key in or leave it blank (either to be filled later or not to be filled at all).

This is not the end. There is yet another enhancement to this. Certain bookmarked urls have query strings, as in case of search urls. The google url: http://www.google.com/ is followed by a query string of the form "search?hl=en&q=search string" which carries the search string entered. Such strings work with the keywords also. Meaning you can search for something on google using the keyword, 'g' like this:

"g any-search-string" . This will be converted to appropriate URL with a proper query string as specified in the bookmark properties. As it appears this of course requires a little bit of extra work. When saving an URL as bookmark, for instance when saving http://www.google.com/ you can save it along with the query string, but the search string being substituted by "%s" and whatever string you specify with the keyword will replace every occurance of %s in the URL. So this is how the bookmark URL will look like:

http://www.google.com/search?hl=en&q=%s ---- with g as the keyword. Now when using this bookmark, if you enter something like this in the URL bar:

"g bookmarks " -- this becomes-- http://www.google.com/search?hl=en&q=bookmarks -- and finally giving you search results for bookmarks.

Now this is how I have arranged my mxr bookmarks:

• http://mxr.mozilla.org/seamonkey/find?string=%s -- with keyword: mxrf
• http://mxr.mozilla.org/seamonkey/ident?string=%s -- with keyword: mxri
• http://mxr.mozilla.org/seamonkey/text?string=%s -- with keyword: mxrt

Now does this method appear too complex and cumbersome? Well mozillians come to your rescue yet again. You can save such enhanced search bookmarks called "Quick Search" bookmarks very easily like this:

Go to the search page and Right-Click on the search bar, and click on: "Add a keyword for this search" . That will give you the small bookmarking dialog, with a field for keyword. All that you have to do is to just enter the keyword that you want and click on OK. All the URL, query string and %s headache is taken care by Mozilla.

Well mozilla is here just to make your browsing experience easier, safer and worthwhile., isn't it?

And I am proud to be associated with this awesome community. ;-)

Happy and Fast Browsing.

Subtle things about s/w code Performance

Any software product is first benchmarked for its performance before it is shipped out. No company/developer wants complains about the performance of the product from its users. This one single thing can make the users to simply move away to another better performing product. And moreover such a complaint would mean inefficient coding and to some extent incompetence of the developers, which we software developers can't really take.

Performance is generally measured with 2 parameters:
1) Time taken by the application
2) Memory consumed by the application

Typically, on current day Desktop systems the memory criteria is almost ruled out, unless the application is really memory consuming like 3D games and other high end stuff.

But time has always been a concern. So many algorithms are developed to solve the same problem, with each algorithm being a good choice under some set of conditions. Those are all the high-funda things involving Math, mainly things like: O(n), Exponential complexity etc, etc..

Apart from these there are a lot of very small things, which appear as very trivial and insignificant but eventually make a lot of difference. I learnt about 2 such things at my work place NI, yesterday when I was working on my first task here. I of course cannot speak of the nature of my work and what exactly I was doing. Here are the generic things that I learnt:


1) Avoid calling a function in a loop, instead pass the data you are iterating in the
loop to the function being called.


Suppose you have a large amounts of data to be processed and you have helper processing function and an actual processing function. The most common way of accomplishing such a task would be to iterate through the data in the helper function and for every single instance of the data call the actual data processing function. This can be optimized to a great extent in a lot of cases. By iterating through the data in the helper function and calling the actual function we introduce a lot of function-call overhead, which obviously eats up a major chunk of time. If possible, which it indeed is in many cases, we should instead pass the large data chunk to the actual data processing function and iterate over there and make the necessary processing then and there itself as and when we fetch an instance of the data.

PS: By data instance here I mean one data unit. Something like an element if the data chunk is an array. If it is an array of structures, then one data instance would be a structure.

This way we reduce the overhead caused due to extensive function calls and there by improving the performance.

2) If we have an if/else block which is hit a lot of times continuously, then we should have the code for the most probably case in the if block.

This is particularly interesting. Yesterday when my tech lead told me about this, I was really surprised that optimization can be done at this level. I liked this very much.

Consider the following code fragment:

for ( execute some times) {
if (aCondition) {
.....
.....
} else {
......
......
}
}

Something like above when compiled into machine language would look like this:

loopLabel: instruction for condition check;
JMP if false to elseLabel
code for true case (if block)
some more code for true case
loop condition check
JMP to loopLabel if true
elseLabel: code for false case (else block)
some more code for false case
loop condition check
JMP to loopLabel if true

This is how the assembly code would look like.
Here the if/else block is repeatedly hit as it is in a loop and is the main body of the loop. In the assembly code when the if condition turns out to be true the code for true case is execute and then a JMP is made to loop beginning. BUT, but, in case of else there will be "2" JMP instructions - one to go to the else block and another to go back to loop beginning. This double jump obviously is an overhead and takes more time for execution. Hence we should try and design the if/else in a such a way the code for the most common or most probable case to be put in the if block, so that a maximum part of the execution happens only with a single jump.

This might seem so stupid or so subtle that may lead to the thinking that the performance gain with this trick is almost negligible. Its not so. Believe me, the gain is really good in most cases where the if/else block is repeatedly hit.

So stop jumping around and start improving your code. ;-)