I have an application with multiple threads that may be run on different hardware. To assist with tuning on different hardware I would like to create a "profiler" that can automatically run a fixed amount of data through using different numbers of threads.

I've thought of several ways of implementing this:

  1. It's a test, so put it in with the unit tests
  2. It's also a part of the app, so make it part of the top level class running the app
  3. It's a helper, so create entirely new class Profiler

I'm leaning toward option 2, because I think it is simplest to implement and seems to fit in well. Anyone have any other ideas or comments?

  • Is this operating system specific or agnostic? Because there are many OS specific tools that do this that you could include with your app. Jan 25, 2011 at 17:57
  • It's Java - system agnostic
    – Michael K
    Jan 25, 2011 at 18:02

1 Answer 1


IMHO I would lean towards option 3 as it allows you to keep your separation of concerns intact. In addition I would build out the profiler as its own entity so that it could get used across other projects/applications if need be.

While you shouldn't build for the unknown; building yourself into a corner via tight coupling is something you want to avoid as well.

  • +1: It's not a "test", since it's not a pass/fail situation. It's not the main app. It's another app in the package.
    – S.Lott
    Jan 25, 2011 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.