Good article i have read on Analysing the Front End performance of any web application. The Key points are .....
SCORN stands for the following:
Size -- Caching -- Order -- Response codes -- Number
Below is the brief explanation of each of the above parameters.
Size: When it comes to website performance, smaller is better. Whether it's a graphic, a script or the base HTML page, it has to get from the server to client at least once, and that trip is bound to take less time when there is less information to transmit. Specifically look for uncompressed graphics and media, object or code duplication, script and styles living outside of the base HTML, and code "minification."
Caching: Any page or object that users will view more than once is worth at least considering caching on the client side. The trick is balancing the relative speed of pages and objects being displayed from cache with the fact that objects displayed from cache may not be the most recent version. Check for Expires settings, ETags and other client-side cache controls to see if they strike a sensible balance between object load time and object freshness.
Order: Possibly the most dramatic user-perceived performance gain can be achieved by requesting component objects in the correct sequence. In most cases, the sequence of objects should be as follows:
Styles/style sheets
Critical content (i.e. what the user came to the page to see)
Relevant media (i.e. graphics related to the critical content)
Incidental content (i.e. non-critical graphics, possibly advertisements)
Scripts
Response codes: Checking response codes for each object can help identify requests for objects that don't actually exist, superfluous redirects and errors that aren't apparent from the browser. Each of those can cost more time than getting the object without error/redirect or eliminating the unused request entirely.
Number: For the most part, fewer is better. But depending on a user's connection speed, several smaller graphics may be faster than one large one. In the vast majority of cases, one external style sheet and one external script file will be fastest. It's worth asking questions if the number of objects impresses you as other than "fewer".
For more details refer to --
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1301766,00.html?track=NL-516&ad=659546&asrc=EM_USC_4391444&uid=4931891
Showing posts with label Performance Tips. Show all posts
Showing posts with label Performance Tips. Show all posts
Friday, October 17, 2008
Wednesday, October 15, 2008
Arraylist - Key Factor
Similar to the one below, another common recommendation would be which is better - ArrayList/Vector/Linked List. There are various factors to consider in saying which is better for example, if we consider retrieval of elements from the list - arraylist is faster than linkedlist but when you consider adding an element at a particular position say '0' then linked list is faster. Lets not go into details now. But overall, in a general scenario, its always recommended to use Arraylist in place of vector. But Will that really help??
Internally, both the ArrayList and Vector hold onto their contents using an Array. But when any new element is inserted into an ArrayList or a Vector, the object has to expand its internal array in case it is overbound. In that scenario, a Vector defaults by doubling the size of its array, while the ArrayList increases its array size by 50 percent. So, in case the arraylist or vector are not defined with initial capacity, the default size would be again 16characters. And then as new elements are being added, it keeps resizing itself apppropriately and you would end up taking a large performance hit.
So, It's always best to set the object's initial capacity to the largest capacity that your program will need. By carefully setting the capacity, you can avoid paying the penalty needed to resize the internal array later. If you don't know how much data you'll have, but you do know the rate at which it grows, Vector does possess a slight advantage since you can set the increment value.
Internally, both the ArrayList and Vector hold onto their contents using an Array. But when any new element is inserted into an ArrayList or a Vector, the object has to expand its internal array in case it is overbound. In that scenario, a Vector defaults by doubling the size of its array, while the ArrayList increases its array size by 50 percent. So, in case the arraylist or vector are not defined with initial capacity, the default size would be again 16characters. And then as new elements are being added, it keeps resizing itself apppropriately and you would end up taking a large performance hit.
So, It's always best to set the object's initial capacity to the largest capacity that your program will need. By carefully setting the capacity, you can avoid paying the penalty needed to resize the internal array later. If you don't know how much data you'll have, but you do know the rate at which it grows, Vector does possess a slight advantage since you can set the increment value.
Use StringBuffer instead of += -- Will this really help??
A very commonly suggested optimization technique for Java is to use a StringBuffer instead of a String when concatenating. Typical reaosn would be that using the + or += operators to concatenate strings causes a new object to be created for each concatenation. On the other hand, the StringBuffer contains an append() method, which allows dynamic string growth without having to create a new String object each time.
But we have a catch here, this can sometimes be observed as ineffecient or not effective as much as it is expected to be. Why? - This can be explained as below.
Take the example
Snip1:: String s1 = "Hello";
s1 = s1 + " XX";
Snip2:: StringBuffer sb = new StringBuffer("Hello");
sb.append("XX");
Now when both the above snips are compiled. In snip1, the compiler is smart enough to recognize when a number of concatenations are going to be executed and automatically creates a StringBuffer. Each concatenation operation is converted to append() calls behind the scenes.
So frankly, manually coding a StringBuffer is unnecessary, unless the following reason is considered.
In order for a StringBuffer to truly optimize concatenation, it must be seeded properly. In other words, it needs to be given an appropriate initial size. This is because the StringBuffer keeps the characters of the string it is maintaining in an array. When append() is called, the StringBuffer checks the size of the character array versus the estimated size of the new string. If the estimated size is larger than the actual array, a new array is created and the old array is copied to the new one. Thus, StringBuffer is not only creating a new object for each concatenation, but it also incurs the overhead of copying all the indexes of the original array.
This can be overhead when using the default constructor. In that case, size defaults to character array of size to a measly 16 characters. The most used scenario in any application coding is SQL String creation. SQL strings assuredly will exceed 16 characters and constantly cause new character array objects to be created. Even using the StringBuffer's constructor that takes in a String only initializes the character array as 16 characters more than the length of the String argument.
Hence, the best way to be sure that the StringBuffer will benefit the performance of your application is to give it a large enough initial seed that it will need to create its character array only once based on your requirement.
But we have a catch here, this can sometimes be observed as ineffecient or not effective as much as it is expected to be. Why? - This can be explained as below.
Take the example
Snip1:: String s1 = "Hello";
s1 = s1 + " XX";
Snip2:: StringBuffer sb = new StringBuffer("Hello");
sb.append("XX");
Now when both the above snips are compiled. In snip1, the compiler is smart enough to recognize when a number of concatenations are going to be executed and automatically creates a StringBuffer. Each concatenation operation is converted to append() calls behind the scenes.
So frankly, manually coding a StringBuffer is unnecessary, unless the following reason is considered.
In order for a StringBuffer to truly optimize concatenation, it must be seeded properly. In other words, it needs to be given an appropriate initial size. This is because the StringBuffer keeps the characters of the string it is maintaining in an array. When append() is called, the StringBuffer checks the size of the character array versus the estimated size of the new string. If the estimated size is larger than the actual array, a new array is created and the old array is copied to the new one. Thus, StringBuffer is not only creating a new object for each concatenation, but it also incurs the overhead of copying all the indexes of the original array.
This can be overhead when using the default constructor. In that case, size defaults to character array of size to a measly 16 characters. The most used scenario in any application coding is SQL String creation. SQL strings assuredly will exceed 16 characters and constantly cause new character array objects to be created. Even using the StringBuffer's constructor that takes in a String only initializes the character array as 16 characters more than the length of the String argument.
Hence, the best way to be sure that the StringBuffer will benefit the performance of your application is to give it a large enough initial seed that it will need to create its character array only once based on your requirement.
Subscribe to:
Posts (Atom)