Singleton and performance

[send2r]

What is the behavior/performance in concurrent access environment for
the following:

SingletonClass {
//no state. Only its own instance.

method() {
//do this
//do that
//send request to a queue
//read from dynamic queue
//return data
}
}

NormalClass {
//some member variables

method() {
//do this
//do that
//send request to a queue
//read from dynamic queue
//return data
}
}


Scenario 1:
---------------
SomeClass {
some method() {
SingletonClass s = SingletonClass.getInstance();
Data data = s.method();
}
}

Scenario 2:
---------------
SomeClass {
some method() {
NormalClass s = new NormalClass();
Data data = s.method();
}
}

Assumption: the method that reads data from queue can take a while to
finish. Each queue request results response in a dynamic queue.

Will Singleton cause a performance bottleneck by serializing
execution?

 

[Matt Humphrey]

What is the behavior/performance in concurrent access environment for
the following:

SingletonClass {
//no state. Only its own instance.

method() {
//do this
//do that
//send request to a queue
//read from dynamic queue
//return data
}
}

NormalClass {
//some member variables

method() {
//do this
//do that
//send request to a queue
//read from dynamic queue
//return data
}
}


Scenario 1:
---------------
SomeClass {
some method() {
SingletonClass s = SingletonClass.getInstance();
Data data = s.method();
}
}

Scenario 2:
---------------
SomeClass {
some method() {
NormalClass s = new NormalClass();
Data data = s.method();
}
}

Assumption: the method that reads data from queue can take a while to
finish. Each queue request results response in a dynamic queue.

Will Singleton cause a performance bottleneck by serializing
execution?

The singleton you've shown does not automatically serialize execution any
more or less than the normal class, presuming that the contents of the
method () are the same. Now if SingletonClass.method had a "synchronized"
keyword on it, that would be different.

Matt Humphrey http://www.iviz.com/

 

[Manish Pandit]

What is the behavior/performance in concurrent access environment for
the following:

SingletonClass {
//no state. Only its own instance.

method() {
//do this
//do that
//send request to a queue
//read from dynamic queue
//return data
}

}

NormalClass {
//some member variables

method() {
//do this
//do that
//send request to a queue
//read from dynamic queue
//return data
}

}

Scenario 1:
---------------
SomeClass {
some method() {
SingletonClass s = SingletonClass.getInstance();
Data data = s.method();
}

}

Scenario 2:
---------------
SomeClass {
some method() {
NormalClass s = new NormalClass();
Data data = s.method();
}

}

Assumption: the method that reads data from queue can take a while to
finish. Each queue request results response in a dynamic queue.

Will Singleton cause a performance bottleneck by serializing
execution?

With the structures above, none of the approaches appear thread-safe.
To achieve thread safety, you will need to synchronize the method, or
synchronize on an object's lock in the code fragment that needs to be
thread safe. Thread safety will cause a performance bottleneck in
multi-threaded environment as it impacts concurrent execution.

-cheers,
Manish

 

[Lew]

With the structures above, none of the approaches appear thread-safe.
To achieve thread safety, you will need to synchronize the method, or
synchronize on an object's lock in the code fragment that needs to be
thread safe. Thread safety will cause a performance bottleneck in
multi-threaded environment as it impacts concurrent execution.

The "queue" could be a class from java.util.concurrent such as
<http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html>


This might obviate the need for 'synchronized'.

Concurrent programs don't have to experience "a performance bottleneck" to be
safe. If that were the case, there'd be no use case for concurrent
programming. In fact, well-designed thread-safe concurrent code will increase
performance in many cases. Even more importantly, it can decouple application
modules from each other, and actually reduce the chance for bugs.

Assuming you do program with thread safety in mind, of course.

Use of API classes such as ConcurrentLinkedQueue simplifies one's job and
decreases risk because we're using standard and (presumably) robust libraries.

 

[Andreas Leitgeb]

What is the behavior/performance in concurrent access environment for
the following:

SingletonClass {
//no state. Only its own instance.
method() {
//do this
}
}

NormalClass {
//some member variables
method() {
//do this
}
}

Assuming that the method() itself doesn't need synchronisation,
(if it does, then the following is moot) you get to compare these
two alternatives:

the new-operator for NormalClass
versus
SingletonClass.getInstance()

In a multithreaded environment you usually need some synchronisation
for implementing the Singleton-pattern itself. (the decision of
whether the class is already instanciated or if that needs to be
done now, must be synchronized, or you may end up with more than one
such class created and only one of those saved for future reference.)
Now that I think this through and based on your alternative of not
singleton'ing at all, that might be not that bad afterall.

If your intention is just to keep the number of instances "low" (but
not necessarily one), then an unsecured getInstance() might give overall
best performance (though I wouldn't call it anything like Singleton then).
If you want a real SingletonClass, it might turn out more expensive than
creating a new instance for every use.

I hope I understood the question correctly, since I understood it
differently than the other three followups I saw before.

 

[Ravi]

Let me ask you one question,
If the SingletonClass doesn't have state why do you think it would
read synchronization?
First analyse the need for synchronization. A good way to start is to
identify the variables that are accessed by multiple threads.

Regards,
Ravi.

 

[Andreas Leitgeb]

Let me ask you one question,
If the SingletonClass doesn't have state why do you think it would
read synchronization?
First analyse the need for synchronization. A good way to start is to
identify the variables that are accessed by multiple threads.

Well, the implementation of GetInstance wasn't specified,
so I assumed that the indeed necessary variable needed
to implement it was just forgotten/omitted to mention,
or it may even have used a static variable of another
class...

If you know of a getInstance()-implementation in the context
of SingletonClasses, that does *not* require *some* variable
to hold that one instance, then please let me know, and I'll
thankfully apologize for having made such a bold assumption.

PS: Because the answer ends up to be before the question.
Why?
Please don't top-post!

 

[Matt Humphrey]

Let me ask you one question,
If the SingletonClass doesn't have state why do you think it would
read synchronization?
First analyse the need for synchronization. A good way to start is to
identify the variables that are accessed by multiple threads.

A stateless class may still need synchronization if the methods it calls in
other classes have state. In the original example it's impossible to tell
if method () requires synchronization, but since the OP's question was about
performance rather than correctness I think it's fair to assume
synchronization is not needed, particularly because the method () body is
intended to be the same for both. Given that the OP asked about
"serializing execution" when there's no apparent synchronization suggests to
me that both methods might have been (or were supposed to have been) marked
synchronized. In that case the singleton version would very likely be
slower because it is synchronizing on only one instance whereas the others
synchronize on distinct instances. Of course, synchronizing on distinct
objects would be pointless because it would mean that no synchronization is
really needed. Synchronization could be used to protect the state of
NormalClass, but because the code of the method() is the same for both
classes it would not be using any of that state and so would not need to be
synchronized.

Matt Humphrey http://www.iviz.com/

 

[Ravi]

A stateless class may still need synchronization if the methods it calls in
other classes have state.

Thats true.. From the given code its not trivial, but I mentioned to
identify variables that are accessed by multiple threads. This also
includes references of any local variables that can escape the method.

In the original example it's impossible to tell

if method () requires synchronization, but since the OP's question was about
performance rather than correctness I think it's fair to assume
synchronization is not needed, particularly because the method () body is
intended to be the same for both. Given that the OP asked about
"serializing execution" when there's no apparent synchronization suggests to
me that both methods might have been (or were supposed to have been) marked
synchronized. In that case the singleton version would very likely be
slower because it is synchronizing on only one instance whereas the others
synchronize on distinct instances. Of course, synchronizing on distinct
objects would be pointless because it would mean that no synchronization is
really needed. Synchronization could be used to protect the state of
NormalClass, but because the code of the method() is the same for both
classes it would not be using any of that state and so would not need to be
synchronized.

Assuming Synchronization is necessary, I really don't see any
performance difference between a single object vs. single ton (from my
understanding of Java Language).

Matt Humphreyhttp://www.iviz.com/

Thanks,
Ravi

 

[Matt Humphrey]

Assuming Synchronization is necessary, I really don't see any
performance difference between a single object vs. single ton (from my
understanding of Java Language).

There isn't. But the OP's example isn't dealing with a single object. In
the NormalClass case he's creating a new object for each invocation of
method(). Each different invocation of method () will be essentially
unsynchronized even if the method itself *is* synchronized because they're
locking on different monitors. There could be multiple instances of
method() in parallel operation (so we certainly have to expect that the
whatever they call will be properly synchronized) In the singleton case only
one method will proceed at a time (serialized execution) because they all
block on the same monitor.

Matt Humphrey http://www.iviz.com/

 

[Andreas Leitgeb]

In the singleton case only
one method will proceed at a time (serialized execution) because they all
block on the same monitor.

This is true indeed, but only under the assumption that the class
(or the method()) itself is declared as synchronized, which I don't
remember to have seen from the OP.
If the class or method is *not* itself synchronized, then the Singleton-
ness will not prevent the method from being executed concurrently.
even if the getInstance() was synchronized, even then method still
could be concurrently executed.

In the particular case that method() really doesn't need any
synchronisation, and a pseudo-Singleton Pattern suffices, then
that is likely faster than both the real Singleton and the "new-
class-each-go" approach.

 

[Matt Humphrey]

This is true indeed, but only under the assumption that the class
(or the method()) itself is declared as synchronized, which I don't
remember to have seen from the OP.

Yes, I was speculating in a prior message that the OP's singleton example
had omitted the synchronization keyword. The question about serialized
execution doesn't seem to make sense without it, but there's no evidence
that it's actually needed.

Matt Humphrey http://www.iviz.com/