Bug 866642

I would expect for rhc domain we are making 1 call to the API description, 1 call to get the list of applications for the domain, and then 1 call for each application to retrieve the list of cartridges.

It prints out the information as it gets it so the pause you see is the time it takes to get a list of cartridges for each application.  Here is how it works:

Login: #roundtrip

Grab domain: # roundtrip
  output domain_header
  domain.applications.each |app|: # roundtrip
    output app_header
    app.cartridges.each |cart|: # roundtrip
      output cart_info


The old code simply got the user_info during login which had a hash of all the applications since we only had support for one domain in the backend.

There are are a number of issues contributing to the slowness here.

1) First we have three extra round trips - this is due to the complexity of the data model increasing.  Persistent connections will eventually negate the issue of multiple connect handshakes.  As for the complexity of the model, it is there for a reason

2) Cartridges now contain a list of their properties which the old code only had the name and type of the cartridge.  Since the backend has to dynamically retrieve these I suspect there is extra overhead for each property added.  We only display the connection url here but we still take the hit for grabbing every property.  This is most likely the biggest slowdown.

3) there is a psychological component - I bet if we load all the data first and display it the delay won't be as noticeable.  The pauses contribute to the feeling that the application is slow.  An even better "fix" is to load into highline's scrollable buffer thereby the pauses are not noticed as the text loads off screen while the user reads.

The issues of using the buffer is we would have to have a mainloop or use threads so the user could interact while it was still loading.  Given that highline has trouble between versions with simple input I would experiment with this option before relying on it in production code.

buffers aren't an option without a heavy refactor.  Highline doesn't have a buffer API.  It simply has the ability to set paging to x number of lines. Since Highline isn't actually buffering output paging only happens if you output more than x lines in one say statement.  Multiple say statements are flushed immediately and no state is kept as to how many lines have been displayed.

Need to create a user story to encompass all the work to fix this issue properly

added as story US3025