We build a workflow-like application. use case 1: The user 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?

c#.netperformancearchitecturecode-generation

Reputation: 24406

Improve perceived performance for workflow application

We build a workflow-like application.

use case 1: The user 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?

Upvotes: 0

Answers (3)

Mike Dunlavey

Reputation: 40669

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.

Upvotes: 3

Adrian K

Reputation: 10215

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).

Upvotes: 0

Yahia

Reputation: 70369

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).

Upvotes: 0

Improve perceived performance for workflow application

Answers (3)

Related Questions