Improve perceived performance for workflow application

We build a workflow-like application.

use case 1: The u开发者_运维百科ser visually builds some workflow and then runs it to see results. Then the user fix the WF and runs again, and again, until he is happy.

use case 2: Once the WF is done the user schedules it to run a few times a day (possibly many times)

My friend says: When the user saves his WF let's first save its model to DB (so we can open later) and then generate c# code for the run time from this model.

• "This is the only way to get good performance at run time, especially when use case #2 implies many runs a day"

I say: Let's just save to DB. Then we will build a generic runtime that runs over the DB rows and executes the model commands (interperter-like).

• This gives much better perceived performance for #1 since waiting for compilation after every fix is frustrating
• this will not have such a big affect on the runtime itself if done correctly

What is your take?

You say the db contains flow control elements like loops and conditionals. That says to me what you are storing in the db is at least a simple procedural scripting language.

When that happens, there will be pressure for enhancements making it more like a "real" language. Something like subroutines will be wanted, with parameters, and variables and expressions.

You can jump ahead on this process by having an actual language, rather than a set of rows in a database, and save it as a text file.

Then a good way to "interpret" it is to actually generate C# code on the fly, and compile/run it on the fly. That can actually happen very quickly.

The reason for doing this is a) no need to write the interpreter, and b) leap-frog the future enhancements.

I think a combination would be ideal:

case #1:
As long the user doesn't schedule the WF use your approach (#1)...

case #2:
when the user schedules a WF then compile (perhaps even asynchronisely, just needs to be ready for the first scheduled run).

My take is that whilst waiting to recompile the workflow every time you modify it will get tedious, I'd rather have the performance benefits when it runs "for real"; so I guess I agree with your friend.

This fits with the current .Net development approach where source-code is complied into byte-code. Once you "think" you've finished with the source code then you might as well compile it, right? Plus you'll get all the benefits of a compile time checks before you decide to deploy.

Sure the JIT does the final compile into machine code - but that steps usually not as long as the first part (source code to byte-code).