chore: autoload TwiML to save memory on load

[philnash]

Works towards fixing #396.

Others are reporting that twilio-ruby takes a lot of memory. My belief is that this is because it is a large library that covers an ever increasing API surface. The issue is not necessarily in that the library is so large, but that the entire thing is loaded in one go with requires for days.

I am going to send a few PRs that update our use of require to autoload where appropriate. autoload only loads the file when the constant (class/module) is used. In this first PR, for those who include the library but don't use TwiML, the files governing TwiML creation will not be loaded into memory. For those that do use TwiML the behaviour will be unchanged. Notably this also moves requiring nokogiri to the TwiML files too. This will not affect a Rails user, but users of frameworks which don't include nokogiri should notice a difference.

This first PR will not significantly reduce the memory usage, but it is a start and smaller PRs are easier to review.

Checklist

• I acknowledge that all my contributions will be made under the project's license
• I have made a material change to the repo (functionality, testing, spelling, grammar)
• I have read the Contribution Guidelines and my PR follows them
• I have titled the PR appropriately
• I have updated my branch with the master branch
• I have added tests that prove my fix is effective or that my feature works (all existing tests pass)
• I have added necessary documentation about the functionality in the appropriate .md file
• I have added inline documentation to the code I modified

[childish-sambino]

Cross-posting this:

Changes look good to me. The only concern that I have (which is minor) is the negative impact of lazy-loading. For example, I previously expected a longer start-up time but quicker run-time (on first invocation). Thoughts on making this opt-in? This was done recently for the twilio-node lib where lazy-load is off by default with an opt-in.

[philnash]

Changes look good to me. The only concern that I have (which is minor) is the negative impact of lazy-loading. For example, I previously expected a longer start-up time but quicker run-time (on first invocation). Thoughts on making this opt-in? This was done recently for the twilio-node lib where lazy-load is off by default with an opt-in.

The more I think about this, the more I think that lazy loading can only have a positive effect for the majority of cases. Given that most applications are not using the full suite of APIs once this can all be split out the loading times and memory impact of the library will be much better and then the first invocation time won't be significantly impacted because loading extra files on the first invocation will be much smaller than loading the whole library too.

Also, we can use things like TwiML and JWT as test cases for this because they are easy to split out like this (these are not complicated PRs) and if users find that they have issues when they use TwiML or Access Tokens in their app we can roll back.

Finally, I'd worry that offering this as opt in would both complicate the code unnecessarily and lead to a number of developers missing out on the memory savings because it would be easy to miss.

What do you think @childish-sambino?

[childish-sambino]

Works for me!