OO vs Opimization

[Lukas Stephienn]

Hi,

While creating an API we hide of course implementation of API. So user of our methods does not know what's going on inside it. It is good. Is it?
But what to do if method performs complicated calculations? User does not know about it, and he his code may be very inefficient.

Of course we may write it directly in documentation. But how do it? Mark as efficient/non-efficient? It's not enough of course. The more details we expose about efficiency of our method, the more user knows about implementation. We don't want that of course.

So maybe indicate about it in method's signature, and name it like calculate*, compute* ? Its not good solution either.

Of course programmer should not think about optimization before everything works perfect, but it is good to make some steps while writing code.

Lets make an example of length() from java.lang.String.

Documentation says:
Returns the length of this string. The length is equal to the number of 16-bit Unicode characters in the string.

And that's all.

Suppose we have code:

for (int i = 0; i < string.length(); i++) {
  System.out.print(string.charAt(i));
} 

It is wide known that below code is inefficient, but suppose we don't know how to improve it. It cannot be done without using profiler tools or looking into method's implementation.

It is simple example, but what if our whole solution for few million dollars is based on inefficient code?

What do you think about it?

[Peer Reynders]

Originally posted by Lucius Stephienn:
It cannot be done without using profiler tools or looking into method's implementation.

It is well known that profiling within a representative operational profile is the only way to reliably locate performance bottlenecks. Even an open implementation isn't sufficient because the build tools could be smart enough to spot an opportunity for optimization and get rid of the problem.

As far as an API goes it is usually a good idea to offer 'collection' versions of methods that create, modify or update single objects - if there is a chance that a �collection� version could be optimized somehow. Initially the 'collection' version could be simple and use the single object version - deferring optimization until later (at which point the single object version could simply become a wrapper on top of the 'collection' version). The documentation should emphasize the existence (and preferred usage for multiple objects) of these 'collection' versions in the documentation of the single object version.

[Garrett Rowe]

As far as an API goes it is usually a good idea to offer 'collection' versions of methods that create, modify or update single objects - if there is a chance that a �collection� version could be optimized somehow. Initially the 'collection' version could be simple and use the single object version - deferring optimization until later (at which point the single object version could simply become a wrapper on top of the 'collection' version). The documentation should emphasize the existence (and preferred usage for multiple objects) of these 'collection' versions in the documentation of the single object version.

Could you give an example of exactly what you mean here?

[Peer Reynders]

Originally posted by Garrett Rowe:
Could you give an example of exactly what you mean here?

Well, a mundane case would be an update/save method on a DAO. Initially you would most likely supply a method that updates/saves a single object or aggregate.

Also provide a version that takes a collection of these objects (or aggregates). Give it a trivial implementation where you iterate over the collection and call the single object version for each element. The collection version depends on the single version.

If it becomes apparent that the 'collection' version is used heavily then you may start looking for some opportunities for optimization (always profile first). Create a stored procedure that accepts array parameters. Modify the collection version to marshal the object information to the SP array parameters and run the save/update in one SP call. At this point of time you can modify the single version to create a local collection into which that one object is inserted and then it delegates to the collection version. Now the single version depends on the collection version.

[ April 17, 2007: Message edited by: Peer Reynders ]