Question

Let us take this example scenario:

There exists a really complex function that involves mathematical square roots and cube roots (which are slower to process) to compute its output. As an example, let us assume the function accepts two parameters a and b and the input range for both the values a and b are well-defined. Let us assume the input values a and b can range from 0 to 100.

So essentially fn(a,b) can be either computed in real time or its results can be pre-filled in a database and fetched as and when required.

Method 1: Compute in realtime

function fn(a,b){

result = compute_using_cuberoots(a,b)

return result
}

Method 2: Fetch the function result from a database

We have a database pre-filled with the input values mapped to the corresponding result:

a   |  b  | result
0   |  0  |   12.4
1   |  0  |   14.8
2   |  0  |   18.6
.   |  .  |    .
.   |  .  |    .
100 | 100 |  1230.1

And we can

function fn(a,b){

result = fetch_from_db(a,b)

return result
}

My question:

Which method would you advocate and why? Why do you think one method is more efficient than the other?

I believe this is a scenario that most of us will face at some point during our programming life and hence this question.

Thank you.

Question Background (might not be relevant)

Example : In scenarios like Image-Processing, it is possible to come across such situations more often, where the range of values for the input (R,G,B) are known (0-255) and mathematical computation of square-roots and cube-roots introduce too much time for the server requests to be completed.

Let us take for an example you’re building an app like Instagram – The time taken to process an image sent to the server by the user and the time taken to return the processed image must be kept minimal for an optimal User-Experience. In such situations, it is important to minimize the time taken to process the image. Worse yet, scalability problems are introduced when the number of such processing requests grow large.

Hence it is necessary to choose between one of the methods described above that will also be the most optimal method in such situations.

More details on my situation (if required):

Framework: Ruby on Rails, Database: MongodB

Answer 1

“More efficient” is a fuzzy term. “Faster” is more concrete.

If you’re talking about a few million rows in a SQL database table, then selecting a single row might well be faster than calculating the result. On commodity hardware, using an untuned server, I can usually return a single row from an indexed table of millions of rows in just a few tenths of a millisecond. But I’d think hard before installing a dbms server and building a database only for this one purpose.

To make “faster” a little less concrete, when you’re talking about user experience, and within certain limits, actual speed is less important than apparent speed. The right kind of feedback at the right time makes people either feel like things are running fast, or at least makes them feel like waiting just a little bit is not a big deal. For details about exactly how to do that, I’d look at User Experience on the Stack Exchange network.

The good thing is that it’s pretty simple to test both ways. For speed testing just this particular issue, you don’t even need to store the right values in the database. You just need to have the right keys and indexes. I’d consider doing that if calculating the right values is going to take all day.

You should probably test over an extended period of time. I’d expect there to be more variation in speed from the dbms. I don’t know how much variation you should expect, though.