So not too long ago I made a rant about this time I told my superiors of a problem and it got shot down because "We don't want to save developer time".

I warned them that the CPU was going to reach it's limit because the issue involves exponential growth on CPU usage the more we develop.

As it turned out, despite my thoughts that we wouldn't reach that limit for over a year, a new development led to it blowing up in their face today.

I am now treated as the expert on the topic and they're rushing to plan my suggested implementation in the next release.

I'm mildly amused.

Congrats! You now have repo++. Use it wisely and keep them safe from their stupid decisions.

Can you share a simplified version of what would cause this? I am curious how you predicted this.

@Demolishun limitation by the system.

Imagine we have two lists and we are comparing each item in list A to each item in list B.

Every release comes with us adding more to both lists.

So you multiply the size of list a to the size of list B, then multiplay that based on how long it takes to do the comparison and you see how long it takes to do them all.

I suggested using custom code to replace that, as well as every other replicable thing we do here to lower how CPU intensive it was and got shot down.

Over the last week, the size of list B has doubled and that forced us into a situation where if the size of list a is 15 or higher, we use our limit of CPU time for this function and it fails.

@LazyLarry So was the comparison brute force equality? This item exists in this list? Or was the comparison more complicated?

The reason I ask is because I was comparing 2 lists when I was doing a coding challenge. I reduced the complexity to filling a hashed container with an integer. Both lists would be processed once which would cause an integer to increment. If any of the entries had 2 then there was a match between the lists. I only had to be careful that everything was unique in each separate list. Due to the comparison being equality I was able to simplify.

@Demolishun it's done this way because we're using out of the box solutions with this system and the client is allergic to customization, ie, custom code.

I did however make the suggestion to minor optimize how we do it, but the problem still exists until we can use code to do it in a single run