Hacker News new | past | comments | ask | show | jobs | submit login

Related, running something like decrypt hugefile.dat | encode outfile.dat will usually result in powershell using up all your system ram and crashing.



On a somewhat related note, one of PowerShell's biggest weaknesses is memory utilization. And since they make it so simple to pass around hefty object collections it tends to bite you in the ass early on. Particularly when you're using cmdlets. When doing real scripting that actually needs to be run as a job I am surprised when I can get away with cmdlets and don't need to manage .net APIs/objects directly. Especially third party cmdlets.

One performance tip I picked up early on: If you're passing around large object sets you need to operate on try to keep them in a pipeline. Populating a variable and interacting with it is arguably more readable and maintainable, especially for junior people, but it has a heavy cost in terms of memory.

That said every version of posh is better than the last so I may be wrong or overestimating the impact for the newest versions. YMMV, don't believe everything you read on the internet, etc.


That is a good tip. There are certain product teams that produced ENORMOUS objects and your suggestion helps when dealing with that.

Jeffrey Snover [MSFT]


Upon reading that again maybe I should have said it's weakness is that it's easy for everyone involved to create objects that use a lot of memory. I'm not sure it's fair to say PowerShell itself is bad at utilizing or managing memory. It's more of a possible negative side effect of one of its great strengths.


That's great advice, man. Cheers.


Most likely because it loads it all into memory, rather than say streaming it.


That's how I would expect MSFT to build it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: