Two years ago, PHP's package manager, Composer, was sped up by disabling the garbage collector:
http://blog.ircmaxell.com/2014/12/what-about-garbage.html
(Or more accurately the cycle collector. You can't turn off reference counting.)
Disabling npm's progress bar yields a 2x npm install speed improvement
161–170 of 187 posts
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#162Earlier quoted context omitted.
No, never had a need for it.
At the risk of getting downvoted myself, I wonder why all of your comments are getting downvoted. Is it such a terrible opinion that it doesn't even belong on HN? A lot of people turn off syntax highlighting. It can be legitimately distracting, and it messes up tooling.
I was asked a question and provided an answer. So I don't care for syntax highlighting or colors in my editor and command line - big deal. I am not imposing my view on others.
When working with a command line one wants npm or any command to run as quickly as possible. Any graphics that slow operation of the command should be an opt-in, not an opt-out.
Everyone is entitled to their opinion, but some people prefer to suppress others' opinion.
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#163Yes, but, which download feels longer?
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#164Earlier quoted context omitted.
> What you have to do is create a thread [...] A thread? But that'll never scale!
What do you want? a whole new process? That doesn't scale either. Come on.
What we need is to put this into a Docker container then parallelize the cloud instances using asynchronous message brokers enterprise
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#165Doing GUI calls is a notorious way to slow down apps. I sped up an app (major software from major large corporation) by a factor of 10x a few years back by removing GUI updates. What you have to do is create a thread that refreshes the GUI periodically and not let your main worker thread ever work on the GUI. This particular app was an Eclipse Plugin (a source control app) and the Eclipse SWT to update the console lo…
> I sped up an app by a factor of 10x
Woah
> This particular app was an Eclipse Plugin
Ah ha ok so it just runs fairly slow now right? :)
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#166Earlier quoted context omitted.
I'm not 100% sure from your comment, but are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? As someone writing a lot of ruby, "give me whatever" is analogous to "give me the latest unless I specify otherwise", which I consider to be a very good default. It keeps me up to date with security issues, and incompatibilities between libraries that the respecti…
> are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? Yes, this is the way that Guix and Leiningen and rebar3 and a bunch of other things work, and it is wonderful. Pulling in new code without you asking is a fine idea for something like apt-get where you have a huge team doing QA on the entire system working together before it even hits your repositories…
[deleted]
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#167Earlier quoted context omitted.
That's frustrating, I got bitten by that a couple of times. I'm wondering when will they add a LOCKFILE like every other build system out there :'(
I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.
PHP have a package manager called Composer which have a lock file.
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#168Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#169Earlier quoted context omitted.
It's really difficult to get to that meaning, because "main thread" is what you call the thread where main() is invoked and which is where all the GUI calls must happen. You can't use a common term in context to mean something different from its common meaning and expect people to follow.
And yet it was perfectly obvious what was meant. If you just assume the person who made the comment is not stupid/rambling (difficult concept, I know...) it is not difficult to get the meaning at all.
I think it's just a "my environment" bias thing going. I don't work on iOS and I immediately understood what was meant by the comment. Of course, the "my environment" bias may also include a degree of the "other" is not as bright as me.
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#170I'd also like to take the time to mention that the caching system when installing / other actions is extremely inefficient (for my times I have the progress bar turned off already and this is a project with around 80 modules shared between dev / prod): https://github.com/npm/npm/issues/10890 I started on a very (I would like to emphasize very a thousand times over) basic proof-of-concept to show how much faster it co…
Looks good. I wonder if it'd be too much scope creep to add extension points for LAN/proxy caching. I know of one small dev team who had a single ADSL connection shared between ~10 people - NPM downloads would have been painful.
I made an npm package that does this https://github.com/vvo/npm-pkgr