Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

111–120 of 187 posts

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

#111

Post by nicklo »

ninkendo wrote: post #94
panic wrote: 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."

Thank you for this. I see now how my wording was unclear, but this is exactly what I had meant. Sorry for the confusing word choice.

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

#112

Post by josegonzalez »

mbell wrote: post #74
juandazapata wrote: post #45

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.

I try and push devs to do

    pip freeze > requirements.txt
Which has a similar effect.

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

#113

Post by moonchrome »

lilyball wrote: post #91
nicklo wrote: post #88

Earlier quoted context omitted.

This strategy is also encouraged by best iOS development practices (main thread never works on GUI). Edit: 'main' as in the one doing the one doing the work, in the same spirit of the original post. In truth, the true main thread that runs in main() is where all the iOS GUI work happens. Apologies for the confusing wording.

This is not only completely wrong, it's dangerously wrong. It is in fact wildly unsafe to touch the GUI from anything except the main thread. It's all the non-UI stuff that you should shove onto another thread.

Depends on what you call "main thread" - maybe he's saying worker thread that's doing the "main code" shouldn't be doing GUI

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

#116

Post by dasil003 »

technomancy wrote: post #104
stormbeta wrote: post #93

Earlier quoted context omitted.

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.

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 respective maintainers resolve amongst themselves with a minimum of manual work.

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

#117

Post by macNchz »

KG8 wrote: post #99
ClayFerguson wrote: post #68

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…

Years ago had a similar albeit smaller discovery. Loading a flash application with a progress bar and setting the quality option to the lowest quality made the bar go faster.

I remember having a few tricks like that–I vaguely remember moving bits of the GUI for some apps off screen so they wouldn't get drawn and thus run faster.

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

#118

Post by freshyill »

Syrup-tan wrote: post #101
freshyill wrote: post #52

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

That did the trick, thanks!

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

#119

Post by freshyill »

Macha wrote: post #77
freshyill wrote: post #52

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

Weird I'm seeing the left result in iterm 2 on my work mac

Check Syrup-tan's comment above for an explanation.

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

#120

Post by technomancy »

dasil003 wrote: post #116
technomancy wrote: post #104

Earlier quoted context omitted.

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.

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, but for most package managers, the dev team is the one doing the testing, and upgrades should be done only with great care.

It does mean you have to watch for security updates, but this is true of all package managers.

Post reply on HN