search

volojs / volo

Create front end projects from templates, add dependencies, and automate the resulting projects
https://volojs.github.io/
Other
1.41k stars 99 forks source link

Download speed question #112

Closed guybedford closed 11 years ago

guybedford commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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.

guybedford commented 11 years ago

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

rafi commented 11 years ago

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 commented 11 years ago

@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.