This is not exponential in growth.

Assuming table1 has N elements and table2 has M elements, this takes O(N*M) time to execute (big-O notation is used to express running times of algorithms. It ignores the exact value of the running time in favor of a simple expression of something approximating proportionality).

Exponential growth would be of the form O(2^N) or O(2^M) or some such.

Okay, now that I am done being pedantic, what about your question.

One suggestion for speeding up the algorithm would be to sort table2 by the special status. If you could group all the elements that should be summed with each element in table1 then you are able to speed up the algorithm to O(N+M) + the cost of the sort. A good sort would be, on average, O(M lg M) (lg is log base 2 but the base of the logarithm is unimportant in big-O). So if lg M is much smaller than N, you would have a net win with sorting the second table. If necessary you could restore the original order (or work on a copy of table2).

Hope this helps, -bcl

Assuming table1 has N elements and table2 has M elements, this takes O(N*M) time to execute (big-O notation is used to express running times of algorithms. It ignores the exact value of the running time in favor of a simple expression of something approximating proportionality).

Exponential growth would be of the form O(2^N) or O(2^M) or some such.

Okay, now that I am done being pedantic, what about your question.

One suggestion for speeding up the algorithm would be to sort table2 by the special status. If you could group all the elements that should be summed with each element in table1 then you are able to speed up the algorithm to O(N+M) + the cost of the sort. A good sort would be, on average, O(M lg M) (lg is log base 2 but the base of the logarithm is unimportant in big-O). So if lg M is much smaller than N, you would have a net win with sorting the second table. If necessary you could restore the original order (or work on a copy of table2).

Hope this helps, -bcl