in reply to Benchmarking Strategy?

pileofrogs,
Typically you profile an application to identify bottlenecks. Then, you write one or more alternatives to the sore spots. Next, you synthesize the input data required by that those routines which is something normally the full application would do. Finally, you Benchmark them.

It sounds like you have two issues. The first is that you don't want to wait until you have a complete application before benchmarking as you suspect you already know where your bottlenecks will be. The second is you can't think of a good way to synthesize the input without having a full blown application.

I am not sure the approach you are going in is the right one. If I have understood correctly, your ultimate dilema is making an up front design decision about your architecture. It is hard to see why the normal process won't work for you. Perhaps you need to give a more concrete explanation. Regarding your idea about tying your benchmarking to your test suite, it sounds like you want Mock::App (non-existent) where the majority of your API is just stubs but the routines that you are interested in testing and benchmarking are complete. I really don't see what this buys you since a good benchmark should really be comparing the smallest possible variations of functionally equivalent routines.

Update: I see your response and will reply with links and further advice when time permits. For starters, you can take a look at the planning and design phases of the software development life cycle (SDLC).

Cheers - L~R

Replies are listed 'Best First'.
Re^2: Benchmarking Strategy?
by pileofrogs (Priest) on Jul 23, 2009 at 19:33 UTC

    ++

    This is exactly the kind of answer I wanted!

    I don't actually know what the normal process is. I've just been flying by the seat of my pants for the last decade...

    Can you point me to some good urls that I could read so I could find out?

    In specific response, how do I profile something that doesn't exist yet? You're exactly right, I'm making an up front design decision. How do I do that?

[reply]
      pileofrogs,
      In specific response, how do I profile something that doesn't exist yet? You're exactly right, I'm making an up front design decision. How do I do that?

      I have already provided you a link to SDLC and ELISHEVA has begun to expand on phases that come earlier in the process - before writing code, such as plan, design, and specification. All of those things feed into a decision for architecture by fleshing out your requirements. In plain English, what you need to know is that you aren't prepared to start writing code without the real possibility of painting yourself into a corner, failing or perhaps creating a monster.

      So without trying to learn the entire SDLC in a day, what you need to do is specify your requirements. Your prototype was too slow - what is fast enough? You said "This means I'm going to have a lot more data and I'm going to search it in a lot more ways" - do you know all the ways you might want to search that data? Do you need to support things like concurrent users (how many) and maintain integrity (ACID transactions)?

      What I am getting at is once you know what requirements your solution must meet, you may not have so many choices. Also, unless you have a clear idea of what your performance requirements are, you should base your decision on things you do have specific requirements for (reliability, scalability, maintainability, flexibility, existing expertise, etc).

      Finally, if you do come up with specific performance requirements and still can't figure out how to test/benchmark them, come back and see us - that's what we are here for.

      Cheers - L~R

[reply]

In Section Seekers of Perl Wisdom