This really depends on your requirements. First, see if you really need a workflow engine (this or other sources). Unless you really need it, probably you should avoid it.
If you really need what provides a workflow engine, I would pick one that is already built. People who works with jbpm or activiti have much more experience than you in building workflow engines, so it is probably already tunned to improve performance.
I agree with the guys that already posted responses here, or part of their responses anyway :P, but as here in the company where I am currently working we had a similar challenge I took the liberty of adding my opinion, based on our experience.
We needed to migrate an application that was using the jBPM workflow engine in a production related applications and as their where quite a few challenges in maintaining the application we decided to see if there are better options on the market. We came to the list already mentioned:
We decided not to use jBPM anymore as our initial experience with it was not the best, besides this the backwards compatibility was broken with every new version that was released.
Finally the solution that we used, was to develop a lightweight workflow engine, based on annotations having activities and processes as abstractions. It was more or less a state machine that did it's job.
Another point that is worth mentioning when discussing about workflow engine is the fact they are dependent on the backing DB - it was the case with the two workflow engines I have experience with (SAG webMethods and jPBM) - and from my experience that was a little bit of an overhead especially during migrations between versions.
So, I would say that using an workflow engine is entitled only for applications that would really benefit from it and where most of the workflow of the applications is spinning around the workflow itself otherwise there are better tools for the job: