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

Download speed question #112

Closed
guybedford opened this issue Nov 26, 2012 · 6 comments
Closed

Download speed question #112

guybedford opened this issue Nov 26, 2012 · 6 comments

Comments

@guybedford
Copy link

I've got a project with 16 dependencies and each repo download takes about 8 seconds to complete (I'm in South Africa, we're not renowned for our fast internet connections). What's interesting is that when I load the URLs directly in the browser, it only takes me about 2 seconds to load that same URL. I know Volo needs to do a repo search and could also be checking the amd-repo list, but I'm still not entirely sure how that is all filling up 8 seconds. Just wondering if there's any scope for speed improvements, because I think it's an important factor for adoption as well.

@jrburke
Copy link
Member

jrburke commented Nov 30, 2012

I expect it to be faster if: owner/repo/version is used, and that has a package.json with a volo.url setting. That will be the minimum number of server round trips. Does that help with the time?

That said, I would like to have a local cache for versioned fetches. I have opened #114 to track that.

@guybedford
Copy link
Author

Thanks, I've updated from owner/repo to owner/repo/version and it seems to be a little quicker. It is difficult to tell since network speeds can vary quite a lot though, but it certainly seems to be an improvement.

There are a couple of other suggestions I was thinking -

  1. Getting one log message for each repo makes it 'feel' slow. When there are lots of messages going through like with npm, it feels more responsive. It's mostly aesthetic, but a log of the various resolutions going on would give the impression of a faster system. The colouring and speed of prompts in bower feels impressive but Volo is still a better system for my needs. It's hardly critical, but perhaps someone may be interested in bringing these aesthetics to Volo?
  2. I'm not sure how Volo works currently, and if it doesn't support this, it would probably involve rewiring, but if downloads could run in parallel as far as possible, loading dependencies onto a queue as resolutions are made, that might also give a big speed boost.

@jrburke
Copy link
Member

jrburke commented Dec 5, 2012

There is issue #3 for colorizing the output. For me, it is more of a gimmick, but I do appreciate it is a nice touch. I am just not sure where to get started with that, so if someone wants to do some investigation, prime the pump and point me to some resources for knowing what to do, I'm all for that if they do not want to do a full patch. We should track that in #3.

For the parallel downloads, I have opened #116 to track the parallel download request, with some notes.

Going to close this as we have specific tickets for suggestions, but feel free to continue discussion in this ticket and we can spin off other tickets as needed.

@jrburke jrburke closed this as completed Dec 5, 2012
@guybedford
Copy link
Author

Wow, a parallel download system would be great.

I'm not sure if this is what you were getting at, but for colouring there is a native intro here:
http://roguejs.com/2011-11-30/console-colors-in-node-js/

And this is the npm module used by jitsu, which seems quite straightforward:
https://github.com/Marak/colors.js

@jrburke jrburke mentioned this issue Dec 10, 2012
@rafi
Copy link

rafi commented Apr 15, 2013

Volojs feels extremely slow. For example volo install codemirror takes around ~2-3 minutes. While using jamjs or bower, with no caching, it takes less than ~15 seconds.

Bower and Jamjs also have a caching mechanism, so if 'codemirror' was already pulled, it will take ~3 seconds to install again.

@jrburke
Copy link
Member

jrburke commented Apr 21, 2013

@rafi: 2-3 minutes seems long, and I expect you hit a case where github was just slow at that moment. I do want volo to go faster though in general, and I am hoping #104 and #116 will go far in addressing that.

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

3 participants