Live data from Hacker News

Disabling npm's progress bar yields a 2x npm install speed improvement

twitter.com

101–110 of 187 posts

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#101

I posted this below, but I'll post again here for visibility. What the heck is up with npm install on iTerm 2? I had no idea something was weird until recently, when I did an install with Termial. Here's a side-by-side video: https://youtu.be/odoVfHHBYVM

I had the same problem (and figured it was normal for a while), after some looking-into it I was able to fix it by unchecking "Treat ambiguous-width characters as double width" [0]

[0] https://denpa.moe/~syrup/Screen%20Shot%202016-01-26%20at%206...

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#102
post #11

Earlier quoted context omitted.

Awesome tool, but wish the url was a bit easier to spell/remember!

I'm not sure "IED" is the best acronym to go for, either: https://en.wikipedia.org/wiki/Improvised_explosive_device

But it's the bomb.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#103

Doing 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…

> What you have to do is create a thread [...]

A thread? But that'll never scale!

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#104
post #74

Earlier quoted context omitted.

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.

You get a similar effect for free with any language whose community defaults to non-floating transitive dependencies, e.g most JVM languages.

Indeed; a lockfile is just a workaround for the problem of "just give me whatever" dependency declarations. Solve the problem at the root rather than piling hacks on it.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#105

Earlier quoted context omitted.

I contracted at Nortel in the mid 1990's. In my cube I somehow acquired a Sun Sparcstation 20 that nobody was using, and found an NCD black-and-white (or was that one grayscale?) X terminal on a shelf somewhere, collecting dust. I found an image for it somewhere, and set it up to TFTP boot from the SS20 (which was running Red Hat Linux) to a login prompt (XDM). It was a nice little setup.

I bet it was. Well done. A couple of years ago I was just about to throw out all my O'Reilly X Window/Motif books from 20 years ago and when I landed a contract to update a K&R C based Motif system running on 32-bit Solaris connected to - of course - Sybase. It felt like I travelled back in time. Old code never dies.

I have X/Window/Motif O'Reilly's from more than 20 years ago which are still shrink wrapped together. I've just been carrying them from place to place.

Must be worth a fortune by now ...

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#106

Doing 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…

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

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#108
post #89

Earlier quoted context omitted.

This is backward. Since UIKit is single threaded, the main thread must work on GUI: the best practice is that nothing except GUI work should happen there.

You're not being charitable enough to the comment... you two are in completely agreement with one another if you only changed the meaning of the word "main". It's clear the grandparent meant "the thread that's doing the work."

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.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#109
post #74

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

Cabal (Haskell) too.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#110
post #34

Earlier quoted context omitted.

I'm not sure "IED" is the best acronym to go for, either: https://en.wikipedia.org/wiki/Improvised_explosive_device

Didn't stop NUKE, PHP Nuke, DotNetNuke, etc.

That brings me way back. Any love for PostNuke out there anymore?
Post reply on HN