Улучшение воспринимаемой производительности для приложения рабочего процесса

Question

Мы создаем приложение, похожее на рабочий процесс.

вариант использования 1: Пользователь визуально создает некоторый рабочий процесс, а затем запускает его, чтобы увидеть результаты.Затем пользователь исправляет WF и запускается снова и снова, пока он не будет доволен.

сценарий использования 2: Как только WF завершен, пользователь планирует запускать его несколько раз в день.(возможно, много раз)

Мой друг говорит: Когда пользователь сохраняет свой WF, давайте сначала сохраним его модель в БД (чтобы мы могли открыть позже), а затем сгенерируем код на C # для времени выполнения.от этой модели.

• «Это единственный способ получить хорошую производительность во время выполнения, особенно когда сценарий использования № 2 предполагает многократное выполнение в день» *

Я говорю: Давайте просто сохраним в БД.Затем мы создадим универсальную среду выполнения, которая будет проходить по строкам БД и выполнять команды модели (по типу интерпретатора).

• Это дает намного лучшую воспринимаемую производительность для # 1, так как ожидание компиляции после каждого исправления расстраивает
• это не окажет такого большого влияния на саму среду выполнения, если все сделано правильно

Что вы берете?

Answer 1

Вы говорите, что БД содержит элементы управления потоком, такие как циклы и условные выражения.Это говорит мне о том, что вы храните в БД, по крайней мере, простой процедурный язык сценариев.

Когда это произойдет, будет необходимость в усовершенствованиях, делающих его больше похожим на «настоящий» язык.Потребуются что-то наподобие подпрограмм с параметрами, переменными и выражениями.

Вы можете ускорить этот процесс, имея реальный язык, а не набор строк в базе данных, и сохраните его в виде текста.file.

Тогда хороший способ «интерпретировать» это на самом деле генерировать код C # на лету и компилировать / запускать его на лету.На самом деле это может произойти очень быстро.

Причиной для этого является: а) не нужно писать интерпретатор и б) перепрыгнуть через будущие улучшения.

Answer 2

Мое предположение состоит в том, что, ожидая перекомпиляции рабочего процесса каждый раз, когда вы изменяете его, он будет утомительным, я бы предпочел выиграть в производительности, когда он будет работать «по-настоящему»; так что я согласен с твоим другом.

Это соответствует текущему подходу к разработке .Net, когда исходный код компилируется в байт-код. Как только вы «подумаете», что закончили с исходным кодом, вы можете скомпилировать его, верно? Кроме того, вы получите все преимущества проверок времени компиляции, прежде чем вы решите развернуть.

Конечно, JIT выполняет окончательную компиляцию в машинный код, но обычно это происходит не так долго, как первая часть (от исходного кода к байт-коду).

Answer 3

Я думаю, что комбинация была бы идеальной:

дело № 1:
Пока пользователь не планирует WF использовать ваш подход (# 1) ...

дело № 2:
когда пользователь планирует WF, то компилирует (возможно, даже асинхронно, просто нужно быть готовым к первому запланированному запуску).