How about implement another Run() in framework::Executor

[Xreki]

Suggested by @qingqing01 , we may implement another Run() in paddle/framework/executor.h which do the same things as the Run() of Python Executor.

Paddle/python/paddle/v2/fluid/executor.py

Lines 125 to 132 in 144854d

	def run(self,
	program=None,
	feed=None,
	fetch_list=None,
	feed_var_name='feed',
	fetch_var_name='fetch',
	scope=None,
	return_numpy=True):

The interface maybe like and will do following things:

void Run(const ProgramDesc& program,
         Scope* scope,
         std::map<std::string, Tensor>& feeds,
         std::map<std::string, Tensor>& fetchs,
         std::string& feed_var_name="feed",
         std::string& fetch_var_name="fetch") {
  1. clone the program
  2. prepend feed_op
  3. set feed variables
  4. append fetch_op
  5. call Run(const ProgramDesc&, Scope*, int, bool create_local_scope = true, bool create_vars = true)
  6. get fetch variables 
}

So that we can directly Run both in Python API and C++ API.

[sidgoyal78]

@Xreki: This idea seems like a reasonable approach to avoid the Resolver class. So I think I would prefer this approach.

(Another comment, just comparing against the Resolver class design: I think steps 1 - 4 which are extra in this design should be relatively cheap in terms of computation. So calling run again and again, in case of inference in a streaming fashion, should be also fine. )

[Xreki]

Can you give some detail about running steps 1-4 in a streaming fashion?

[sidgoyal78]

I just was saying that if we call the Run() function again and again:

• in the previous design with ProgramResolver and the current design, the only repetitive part that i see is steps 1 to 4 in the above function.
  So I think this should be fine since these steps are not costly..

[Xreki]

OKay. It seems an optimization method. I add it to the TODO list in inference framework project to remark it.