Asset Details
Do you wish to reserve the book?
Design for performance, Part 1: Interfaces matter; Avoid performance hazards when designing Java classes
Hey, we have placed the reservation for you!
By the way, why not check out events that you can attend while you pick your title.
Oops! Something went wrong.
Looks like we were not able to place the reservation. Kindly try again later.
Are you sure you want to remove the book from the shelf?
Design for performance, Part 1: Interfaces matter; Avoid performance hazards when designing Java classes
Do you wish to request the book?
Design for performance, Part 1: Interfaces matter; Avoid performance hazards when designing Java classes
Please be aware that the book you have requested cannot be checked out. If you would like to checkout this book, you can reserve another copy
We have requested the book for you!
Your request is successful and it will be processed during the Library working hours. Please check the status of your request in My Requests.
Oops! Something went wrong.
Looks like we were not able to place your request. Kindly try again later.
Magazine Article
Design for performance, Part 1: Interfaces matter; Avoid performance hazards when designing Java classes
2001
Overview
The String class is a major source of object creation in programs that manipulate text. Because Strings are immutable, a new object must be created each time a String is modified or constructed. As a result, performance-conscious programmers avoid excessive use of String. However, this is often impossible. Even when you eliminate reliance on String from your code, you frequently find yourself using components whose interfaces are defined only in terms of String. Thus, you end up being forced to use String anyway. It's bad enough that BadRegExpMatcher forces you to provide it with input in the form that it wants to see, rather than in the form that you can more efficiently provide. But using BadRegExpMatcher comes with another risk, one that is potentially even more hazardous to MailBot's performance: You began with the noble intention of avoiding the use of Strings when processing the mail headers. But since you are forced to create many String objects anyway to satisfy BadRegExpMatcher, you might be tempted to abandon that goal and use String even more liberally. Now, one component's bad design has infected the program that uses it. Even if you later find a better regular expression component that doesn't require you to provide it with a String, your whole program might be infected by then. BadRegExpMatcher forced MailBot to convert the input text from the character array it already had into a String, resulting in an unnecessary object creation. Ironically, many implementations of BadRegExpMatcher would immediately convert that String right back into a character array for easy access to the input text. Not only does this allocate yet another object, but it means that you performed all that work only to end up with the same representation that you started with. Neither MailBot nor BadRegExpMatcher actually wanted to deal with a String -- String just seemed like the obvious format for exchanging text between components.
Publisher
Foundry
Subject
