Posts Tagged ‘Java’

Java: String Concatenation

Monday, April 6th, 2009

So, after spending a couple of hours trying to figure out why a particular function was so slow compared to my expectations, I realized my issue dealt with the fact that I forgot about String.concat. I had embedded in my head the past year to always use StringBuilder when possible when concatenating strings. After figuring out why another method was considerably faster, I started to dig into the performance. It is there I realized that String.concat existed and is actually faster in certain cases. Wanting to understand this more, I did a full thorough analysis and comparison. Now, I realize that several others have already undergone this and produced similar results, so you ask, why go through it all again? Well, I wanted to (A) personally verify it myself to learn and understand more (B) dig into the inner depths of the byte code and java code to understand exactly why and (C) to provide more concrete examples and use cases. That being said, continue reading below for my full analysis including my DO lists.

If you do not choose to read any further, at least read the following DO’s:

  • DO use the plus operator if all operands are constants
  • DO use String.concat if only concatenating 2 strings
  • DO use StringBuilder within a for loop when updating values
  • DO use StringBuilder if concatenating more than 2 strings
  • DO use StringBuilder rather than re-assigning variables multiple times
  • DO ensure StringBuilder has proper sizing

(more…)

Building Scalable Servers

Thursday, April 2nd, 2009

As part of my new iPhone project to build a new game, I need to have a backend server to communicate with all the members in order to sync and dynamically update on the fly.  Knowing the iPhone and its possibilities, I want to plan for a highly optimistic future in which thousands of concurrent connections take place.  The transactions will be minimal and compressed to conserve bandwidth, but will occur frequently to monitor player actions and provide alerts to other players as they are interacted with.  So, my immediate question was where do I start.  I obviously have two primary choices:  HTTP or proprietary.  Let’s look into each option a little more in depth.

(more…)

JSF Performance Improvements: Part I

Saturday, October 18th, 2008

This is my first post on improving sites utilizing JSF. This post is more relevant for mostly static content that only changes at the result of database updates. One of the easiest ways to improve performance is through caching. There are several types of caching from database caching (JPA/Hibernate), model caching (EHCache), browser caching (resources, images, etc). The method I will discuss is creating a page cache within JSF. Note that this useful only when using a standard server and do not have access to higher end equipment such as routers that can automatically provide a page caching layer. If that equipment is available, those layers should always be used as they are built for that purpose. However, for simple sites looking for millisecond access times, this can be a pretty easy implementation.

To start, a high level overview. Whenever any JSF page is requested, we will check the cache, and if not available, we will delegate to JSF while also saving to cache. If it is in cache, we will merely use that file rather than going through the JSF lifecycle. HTTP servers are very fast/efficient at serving static resources, so you should easily see millisecond access times.

(more…)

JSF Relative Client IDs

Monday, October 13th, 2008

Currently in JSF, if you wish to have one component refer to another component, you have to use one of two types of client ids: absolute or relative. A relative id is resolved against its closest parent NamingContainer and searches for a suitable match. An absolute id starts with a separator character (typically a colon) and references the top most view root object of the tree. These solutions both work great and generally you rarely need to use absolute ids, which I always feel should be strayed away from as it adds to maintenance and bug leaks. For example, if you change a parent client id, you may forget to update absolute ids that had depended on that particular id. The result is a broken page that may slip through testing leading to bugs. Thus, I always prefer relative URIs when possible. However, in JSF there is no good way in 1.x to refer to parent element relatively. For example, if you have a component within an iterative component (data table, repeat, etc) and wish to refer to a component outside the iterative section, you must currently use an absolute id. Using a relative id would result in a failed lookup as the relative URI only resolves against the closest naming container, which would be the iterative section. However, using an absolute URI (which does work) results in harder to maintain code. A more ideal solution, IMO, is to use relative paths such as Linux (or most other operating system shells) to refer to the outer parents. For example, given the previous iterative example, you could use an expression such as for=”..:child:id” where “..” goes to the parent naming container of the closest naming container. Now, you have relative URIs and much easier to maintain code by not having to worry about potential id changes to the root element, for example.

Controlling GC and Improving Unit Testing through Factories

Monday, October 13th, 2008

So I was looking at design patterns and read across the factory pattern and the pooling pattern. I know what both of those do independently but never considered them together and as a result, my mind started racing with ideas. One of the many problems with applications in terms of performance is garbage collection. Pooling helps to solve this problem by reusing objects that have been released back to the pool. One of the big problems with unit testing is testing classes in pure isolation by properly injecting mock objects that are dependencies of the class under test. IoC helps to resolve this issue by injecting code into classes. However, you still have to at times use ‘new’ to create objects. This causes three big issues. First, the VM has to create a new object, initialize it, and add it to the stack. This is an expensive task. Second, you put dependency into the code. Further, if you utilize pooling you add yet another dependency (think coupling here). Third, using new does not allow you to truly run code in isolation as your class under test is not invoking code on another object without being able to use a mock instance.

So, how can you solve these problems, you ask, and what do they have to do with factory and pooling design patterns? Well, let’s go back to my initial remark on the factory and pooling design patterns. First, we will talk about the factory design pattern. A factory design pattern is simply a class that loads or creates other classes. That is exactly what we want to do. Further, this allows us to do a few things. First, it abstracts how an object is created and lets you add custom handling to any type of object by simply using a different factory. This helps to reduce other less performance-based solutions such as AOP or adapters and wrappers. Second, it removes the usage of the new operator so that you can easily mock the class under test in pure isolation by registering mock objects with the factory. Third, it promotes loose coupling by not having classes worry about pooling, initialization, etc. POJOs only depend on the Factory as a simple static object. With that said, let’s look at some examples to further clarify.

(more…)