Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: Performance better with while loop #57

Open
apotonick opened this issue Nov 24, 2022 · 6 comments
Open

Idea: Performance better with while loop #57

apotonick opened this issue Nov 24, 2022 · 6 comments

Comments

@apotonick
Copy link
Member

In Circuit#call, a while loop that also doesn't call termini anymore improves from 1.23 to 1.55.

def call(args, start_task: @start_task, runner: Runner, **circuit_options)
        circuit_options = circuit_options.merge(runner: runner) # TODO: set the :runner option via arguments_for_call to save the merge?
        task            = start_task
        last_signal = nil

        while ! @stop_events.include?(task) do
          last_signal, args, _discarded_circuit_options = runner.(
            task,
            args,
            **circuit_options
          )

          # Stop execution of the circuit when we hit a stop event (< End). This could be an task's End or Suspend.
           # if @stop_events.include?(task)

          if (next_task = next_for(task, last_signal))
            task = next_task
          else
            raise IllegalSignalError.new(
              task,
              signal: last_signal,
              outputs: @map[task],
              exec_context: circuit_options[:exec_context], # passed at run-time from DSL
            )
          end
        end

        return [ last_signal, args ]
      end
@apotonick
Copy link
Member Author

In DSL, we could use the Start event for modelling, only, and skip it when compiling the activity.

@apotonick
Copy link
Member Author

In Circuit#call, it should be return [task, args]

@apotonick
Copy link
Member Author

It is slower to call the Runner with **circuit_options. The Runner could internally do that when calling the task.

runner.(
            task,
            args,
            circuit_options
          )

@apotonick
Copy link
Member Author

It seems that

return [last_signal, args]

is faster than

return last_signal, args

@apotonick
Copy link
Member Author

The entire idea of the circuit interface with a nested (ctx, flow_options) and a kw **circuit_options is probably not so clever anymore, we could simply pass all three as positionals, maybe that's a ton faster?

@apotonick
Copy link
Member Author

TODO: check if caller_locations in DSL.apply_step_on_sequence_builder makes it slower. We need it for deprecation warnings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant