3 added 62 characters in body
source | link

We have a class that has been properly identified for optimization. We've done the profiling and testing, and it's a problem.

Now we have two possible approaches for optimizing this class:

  1. There is some very low-hanging fruit. We can rewrite this in a few days in such a way that the interface and results aren't changed, so we don't have to change any code that uses the class. We can see what effect this has on performance and go from there. This seems to me to be a very low risk, low investment approach.

  2. Since we're already going to be making changes, we could go all out in our optimization. The suggested approach would implement a third-party engine and require us to change the code that uses this class, as well as transform the existing client data that is sent to the class into a format usable by the third-party engine. This may not take too much longer to code, but there would be much more testing required. This seems like a very high-risk, high-investment change and will require a lot of extra testing to make sure we don't break the calling code and don't break the existing client data.

Without testing itI of course can't test ahead of time, but the second approach will probably execute more quickly and be fastermore memory-efficient. However, I'm not sure how much faster, and I'm not sure if the extra effort will even be worth it. I'm not sure that once we made the low-risk changes, we would still consider the the code to be a valid target for optimization.

You can probably guess which approach I would rather take. I'm at odds with a coworker on this one.

So here's my question: Is the second option premature optimization despite the fact that we've already identified this code for optimization? What's the approach that should be taken in this situation?

We have a class that has been properly identified for optimization. We've done the profiling and testing, and it's a problem.

Now we have two possible approaches for optimizing this class:

  1. There is some very low-hanging fruit. We can rewrite this in a few days in such a way that the interface and results aren't changed, so we don't have to change any code that uses the class. We can see what effect this has on performance and go from there. This seems to me to be a very low risk, low investment approach.

  2. Since we're already going to be making changes, we could go all out in our optimization. The suggested approach would implement a third-party engine and require us to change the code that uses this class, as well as transform the existing client data that is sent to the class into a format usable by the third-party engine. This may not take too much longer to code, but there would be much more testing required. This seems like a very high-risk, high-investment change and will require a lot of extra testing to make sure we don't break the calling code and don't break the existing client data.

Without testing it, the second approach will probably be faster. However, I'm not sure how much faster, and I'm not sure if the extra effort will even be worth it. I'm not sure that once we made the low-risk changes, we would still consider the the code to be a valid target for optimization.

You can probably guess which approach I would rather take. I'm at odds with a coworker on this one.

So here's my question: Is the second option premature optimization despite the fact that we've already identified this code for optimization? What's the approach that should be taken in this situation?

We have a class that has been properly identified for optimization. We've done the profiling and testing, and it's a problem.

Now we have two possible approaches for optimizing this class:

  1. There is some very low-hanging fruit. We can rewrite this in a few days in such a way that the interface and results aren't changed, so we don't have to change any code that uses the class. We can see what effect this has on performance and go from there. This seems to me to be a very low risk, low investment approach.

  2. Since we're already going to be making changes, we could go all out in our optimization. The suggested approach would implement a third-party engine and require us to change the code that uses this class, as well as transform the existing client data that is sent to the class into a format usable by the third-party engine. This may not take too much longer to code, but there would be much more testing required. This seems like a very high-risk, high-investment change and will require a lot of extra testing to make sure we don't break the calling code and don't break the existing client data.

I of course can't test ahead of time, but the second approach will probably execute more quickly and be more memory-efficient. However, I'm not sure how much faster, and I'm not sure if the extra effort will even be worth it. I'm not sure that once we made the low-risk changes, we would still consider the the code to be a valid target for optimization.

You can probably guess which approach I would rather take. I'm at odds with a coworker on this one.

So here's my question: Is the second option premature optimization despite the fact that we've already identified this code for optimization? What's the approach that should be taken in this situation?

2 edited title
source | link

Premature optimization possible in deciding how a class is optimized once it has been identified for optimizationto optimize?

Sorry if my title isn't clear.

We have a class that has been properly identified for optimization. We've done the profiling and testing, and it's a problem.

Now we have two possible approaches for optimizing this class:

  1. There is some very low-hanging fruit. We can rewrite this in a few days in such a way that the interface and results aren't changed, so we don't have to change any code that uses the class. We can see what effect this has on performance and go from there. This seems to me to be a very low risk, low investment approach.

  2. Since we're already going to be making changes, we could go all out in our optimization. The suggested approach would implement a third-party engine and require us to change the code that uses this class, as well as transform the existing client data that is sent to the class into a format usable by the third-party engine. This may not take too much longer to code, but there would be much more testing required. This seems like a very high-risk, high-investment change and will require a lot of extra testing to make sure we don't break the calling code and don't break the existing client data.

Without testing it, the second approach will probably be faster. However, I'm not sure how much faster, and I'm not sure if the extra effort will even be worth it. I'm not sure that once we made the low-risk changes, we would still consider the the code to be a valid target for optimization.

You can probably guess which approach I would rather take. I'm at odds with a coworker on this one.

So here's my question: Is the second option premature optimization despite the fact that we've already identified this code for optimization? What's the approach that should be taken in this situation?

Premature optimization possible in how a class is optimized once it has been identified for optimization?

Sorry if my title isn't clear.

We have a class that has been properly identified for optimization. We've done the profiling and testing, and it's a problem.

Now we have two possible approaches for optimizing this class:

  1. There is some very low-hanging fruit. We can rewrite this in a few days in such a way that the interface and results aren't changed, so we don't have to change any code that uses the class. We can see what effect this has on performance and go from there. This seems to me to be a very low risk, low investment approach.

  2. Since we're already going to be making changes, we could go all out in our optimization. The suggested approach would implement a third-party engine and require us to change the code that uses this class, as well as transform the existing client data that is sent to the class into a format usable by the third-party engine. This may not take too much longer to code, but there would be much more testing required. This seems like a very high-risk, high-investment change and will require a lot of extra testing to make sure we don't break the calling code and don't break the existing client data.

Without testing it, the second approach will probably be faster. However, I'm not sure how much faster, and I'm not sure if the extra effort will even be worth it. I'm not sure that once we made the low-risk changes, we would still consider the the code to be a valid target for optimization.

You can probably guess which approach I would rather take. I'm at odds with a coworker on this one.

So here's my question: Is the second option premature optimization despite the fact that we've already identified this code for optimization? What's the approach that should be taken in this situation?

Premature optimization in deciding how to optimize?

We have a class that has been properly identified for optimization. We've done the profiling and testing, and it's a problem.

Now we have two possible approaches for optimizing this class:

  1. There is some very low-hanging fruit. We can rewrite this in a few days in such a way that the interface and results aren't changed, so we don't have to change any code that uses the class. We can see what effect this has on performance and go from there. This seems to me to be a very low risk, low investment approach.

  2. Since we're already going to be making changes, we could go all out in our optimization. The suggested approach would implement a third-party engine and require us to change the code that uses this class, as well as transform the existing client data that is sent to the class into a format usable by the third-party engine. This may not take too much longer to code, but there would be much more testing required. This seems like a very high-risk, high-investment change and will require a lot of extra testing to make sure we don't break the calling code and don't break the existing client data.

Without testing it, the second approach will probably be faster. However, I'm not sure how much faster, and I'm not sure if the extra effort will even be worth it. I'm not sure that once we made the low-risk changes, we would still consider the the code to be a valid target for optimization.

You can probably guess which approach I would rather take. I'm at odds with a coworker on this one.

So here's my question: Is the second option premature optimization despite the fact that we've already identified this code for optimization? What's the approach that should be taken in this situation?

1
source | link

Premature optimization possible in how a class is optimized once it has been identified for optimization?

Sorry if my title isn't clear.

We have a class that has been properly identified for optimization. We've done the profiling and testing, and it's a problem.

Now we have two possible approaches for optimizing this class:

  1. There is some very low-hanging fruit. We can rewrite this in a few days in such a way that the interface and results aren't changed, so we don't have to change any code that uses the class. We can see what effect this has on performance and go from there. This seems to me to be a very low risk, low investment approach.

  2. Since we're already going to be making changes, we could go all out in our optimization. The suggested approach would implement a third-party engine and require us to change the code that uses this class, as well as transform the existing client data that is sent to the class into a format usable by the third-party engine. This may not take too much longer to code, but there would be much more testing required. This seems like a very high-risk, high-investment change and will require a lot of extra testing to make sure we don't break the calling code and don't break the existing client data.

Without testing it, the second approach will probably be faster. However, I'm not sure how much faster, and I'm not sure if the extra effort will even be worth it. I'm not sure that once we made the low-risk changes, we would still consider the the code to be a valid target for optimization.

You can probably guess which approach I would rather take. I'm at odds with a coworker on this one.

So here's my question: Is the second option premature optimization despite the fact that we've already identified this code for optimization? What's the approach that should be taken in this situation?