Improved startup time

[tmbo]

Proposed changes:

• avoid importing tensorflow where possible in CLI (tensorflow has an import time of ~4s)
• command to profile imports locally (requires https://github.com/nschloe/tuna to be installed and python >= 3.7):

  python -X importtime -m rasa.__main__ --help  2> import.log
  tuna import.log
  

• fixes Improve Rasa CLI start-up time #4280
• added a test to avoid a regression (checks if tensorflow gets imported on CLI start)

Status (please check what you already did):

• added some tests for the functionality
• updated the documentation
• updated the changelog (please check changelog for instructions)
• reformat files using black (please check Readme for instructions)

[tmbo]

changes make the commands --help & init a lot quicker, but I don't think it makes sense to merge anything without a change as it is very easy to break this again.

[wochinge]

Thanks for tackling this! This is both amazing for the users and our CI speed 🚀

Regarding the regression test: How about testing for the tensorflow import instead of a certain timing? E.g. you could write a script which

• imports rasa
• sets sys.argv according to the commands you want to test
• runs the command (maybe with mocked behavior)
• assert that tensorflow isn't in the imported modules

[tmbo]

ready for another review 😉

[wochinge]

Thanks for wrapping this up so quickly! Let a few more minor comments but good to go from my side!

[wochinge]

@tmbo How severe is the problem with clashing imports? Would be nice to get it in the release today 👀

[tmbo]

@wochinge I made the other changes, but I can't look into the import issue today, my suspicion is that it worked beforehand because had

from rasa.train import train

in rasa.__init__ which populated the global state FIRST with rasa.train (module) and AFTERWARDS with rasa.train() (function) - due to the evaluation order.

Now, we are not importing rasa.train (module) in init anymore, which means that as soon as we do that for the first time, it apparently overwrites the defined function (and apparently windows is using a different resolution logic here?)

state on master:

state on this branch:

[tmbo]

If you have time to investigate or try moving this around I am happy to help but I won't have enough time today to dig deeper myself 😞

[wochinge]

Thanks for the heads up. I'll have a short look but it doesn't seem like something we should rush just to get it in the release. Especially as it might require change to our Python API.

[tmbo]

I mean there is one quick solution we could try: move the functions back into the original modules and move all the imports in there into the functions (or at least all rasa ones). That will likely work and we could revisit this later.

[wochinge]

I mean there is one quick solution we could try: move the functions back into the original modules and move all the imports in there into the functions (or at least all rasa ones). That will likely work and we could revisit this later.

This seems way harder to maintain. I'm in favor of having these things explict. In my opinion it would be fine to rename the modules (e.g. train -> model_training, test -> model_testing and create_agent from run can go to server.py). They are not part of the official Python API as the official Python API is to use rasa.train(...) etc. so in my opinion this would be ok to do, what do you think?

[tmbo]

well, if they don't appear in the docs I am good with that 👍

[wochinge]

I searched

• import rasa.core
• import rasa.nlu
• import rasa.test
• from rasa import
• from rasa.core (has matches but not related to train, run, test
• from rasa.nlu
• from rasa.test

and had 0 matches 🎉 So good to rename 🚀

[tmbo]

yes that makes sense 👍

[tmbo]

@wochinge are you able to make these changes? Otherwise I'll put it in enable's inbox to make these additional changes.

[wochinge]

Sure, will wrap it up later 👍🏻

[wochinge]

What about deleted the __init__ imports (here and here) instead of renaming the train / visualize in rasa.core and train / test in rasa.nlu?

They aren't used except by us and in my opinion users should rather go through the __init__ imports in rasa or rasa.model_training, what do you think? This also avoids needless imports this stuff.

[wochinge]

moved from rasa.run

[wochinge]

@tmbo Changes are ready. Do you have time for a short review? 🙌🏻

[tmbo]

@wochinge can't approve since I opened the PR - but changes look good 👍