Performance Design (2) Influence of Temporary Object on Software Performance Liu Yanqing Yesky
The existence time of the temporary object is generally short-lived. In addition to the container of other data, there is no other use, developers generally use it to pass data or return data from the method. The first part of the article explores how to create a temporary object affects program performance, and the appropriate class interface design can effectively reduce the creation of temporary objects. By avoiding an interface to design such an interface, the creation of temporary objects can be reduced, and the degree of impact on the performance performance can be reduced. In this article, I will discuss excessively to create temporary objects and provide some mature techniques in the following article to avoid excessive creating temporary objects.
Just say NO for String?
Speaking of creating a temporary object, the String class is the largest "culprit". To illustrate this, I developed an example of an expression matching class in the first part of this article and demonstrated a very normal interface because it had a better interface because of the creation of a temporary object. Similar class runs is slow. Below is an interface for the initial and better performance:
BadRegexpmatcher
Public class badregexpmatcher {
Public badregExpmatcher (String Regex);
/ ** Match the input text with a specific expression, return the matching text if the match is matched, otherwise return empty characters * /
Public String Match (String INPUTTEXT);
}
BetterRegexpmatcher
Class betterRegexpmatcher {
Public BetterRegexpmatcher;
/ ** Provides multiple formats to the matching subroutines, the String, the character array, and the character array subset. Returns -1 if you do not match, if you match, return the offset at the beginning of the match * /
Public int match (String InputText);
Public int match (char [] inputtext);
Public int match (char [] inputtext, int offset, int length);
/ ** If you match, return the length of the match, the call program can rest and construct the matching text from the start of the returned match start. * /
Public int getMatchLength ();
/ ** If the call program needs, this routine can easily construct a matching string * /
Public String getMatchtext ();
}
A large number of programs using BadRegexpmatcher is slower than running the program with BetterRegexpmatcher. First, the calling program must create a String object to pass the parameters to match () () must also create a String object returns a match to the calling program. Each time the call will create two objects, which sounds there is no big problem, but if you frequently call Match () (), creating this two objects have great effect on performance. The performance issues of programs that use BadRegexpmatcher are not stem from their encoding, which is inevitably created by interfaces that are designed, and the creation of temporary objects is inevitable.
BetterRegexpmatcher replaces String objects used in match () in a relatively simple data type (array), so that data is not required to pass data between calling programs and match ().
Since the design phase is better to better avoid program performance after completion of the entire program, you should have more time to handle this issue on how to handle the object's creation of the object. In regexpmatcher, its method requires input and return String objects that may have a potential impact on performance, because the object of the String class is not variable, so the String class object parameters will be required to create a new String object. Since the invariability is usually created with additional objects, "Dumps" must be "re-act" in its invariability, and many programmers will define the unality of the object to affect the performance of the program. In fact, the real situation is much more complicated. In fact, the invariance can sometimes improve the performance of the program, and the variable object can also cause a decline in program performance, and the impact of variability on program performance depends on its usage.
The program often operates and modifies the text string. It is indeed a trouble. When you operate each time, such as finding or selecting a prefix or substring, convert it to uppercase or lowercase, or incorporate two strings into a new string, you must create a new String Class object.
On the other hand, we can freely share an unambiguous object's address without having to worry that the object will be changed. At this time, the non-variable object is much better than the variable object. Variable object also there is a temporary object problem
In regexpmatcher, when a method returned by a method is a String class, it is necessary to create a new String class object. One of the problems existing in BadRegexpmatcher is that Match () returns an object instead of a simple type of data, because a method returns an object, does not mean you will create a new object. Consider the geometry in java.awt, such as Point and Rectangle, one Rectangle is only consisting of four integers, the left corner of x, y coordinates, and the width and height, the AWT component class stores the location of the component and passes GetBounds () method returns it as a Rectangle class object:
Public Class Component {... public reccTangle getBounds ();
In the above example, the getBounds () method only has a auxiliary effect, which is just a declaration of relevant information inside the component. GetBounds () really must create the Rectangle object it returns? Maybe this, let's take a look at getBounds () code:
Public Class Component {... protected reprutangle mybounds;
Public Rectangle getBounds () {return mybounds;}}
When there is a program called getBounds () in the above example, the new object is not created because the component already knows its location, so getBounds () is more efficient. However, Rectangle variability also caused other issues, what kind of situation occurs when a program calling it performs the following code?
Rectangle r = component.getbounds (); ... r.Height * = 2;
Because Rectangle has variability, the above code will cause changes in components, and for the GUI tools like AWT, this will be catastrophic, because when a component changes, you need to re-refresh the screen, but also need notification events Monitor. Therefore, the operation of Component.getBounds () is quite dangerous, the way shown below is more secure:
Public Rectangle getBounds () {return new rectangle (mybounds.x, mybounds.y, mybounds.height, mybounds.width);}, but, like regexpmatcher, each call getBounds () creates a new object, below The code will create four temporary objects:
INT x = component.getbounds (). x; int y = component.getbounds (). Y; int h = component.getbounds (). Height; int w = component.getbounds (). width;
For String classes, creating objects are necessary because String is not variable. However, in this example, creating a temporary object seems to be necessary, because Rectangle has variability, we can avoid such problems caused by String by using any objects that do not use any objects in the interface. Although this program is not always feasible or desirable in situations similar to regexpmatcher, but fortunately, some techniques can be used when designing categories, which can use small objects and will not encounter too much. The problem caused by many small objects.
