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

Composer – Disable GC when computing deps and refs

github.com

Post reply on HN
Print view View original

21–30 of 135 posts

Re: Composer – Disable GC when computing deps and refs

#21

Post by jcampbell1 »

dec0dedab0de wrote: post #10

Could someone more versed with PHP, and this project explain why turning off garbage collection helped so much? and why they didn't turn it back on at the end of the function?

PHP is reference counted, so memory is typically freed as soon as an object is no longer needed. Cycles are the exception which can cause memory leaks, so in version 5.3 php added a cycle collector, which reads every object in memory and very occasionally deletes objects that are disconnected and have greater than zero reference counts (cycles).

In my opinion, the php cycle collector is a pointless waste of time. In objective-c, apple just let's the memory leak by default, and they give you tools to find the leaks, and then you modify the code to break the cycles.

There is no need to turn cycle collection back on at the end of the program, because OS frees the memory at program termination.

Re: Composer – Disable GC when computing deps and refs

#22

Post by rossriley »

DangerousPie wrote: post #12

Interesting. I was looking at the comments hoping for some more technical background, but unfortunately they seem to have been run over by the animated gif crowd. Any more details on this?

It seems when you start to hit the memory limit PHP's automatic garbage collection will loop through the constructed objects to see if any can be cleaned up.

If none can (and in the case of Composer all the objects exist for a reason) then it's wasting time analysing the objects.

So in this case there's only a large waste of cpu doing nothing with gc enabled.

Re: Composer – Disable GC when computing deps and refs

#23

Post by joshuacc »

meowface wrote: post #17
shaurz wrote: post #14

Wait, when did Github become the new 4chan?

It's much closer to reddit than 4chan, otherwise the nature of the images posted would be a little different. And it's been like this for 2 or 3 years now. I've seen comment spam of images for commits and issues for quite a while.

The first one I remember was the commit that added CoffeeScript to rails by default. https://github.com/rails/rails/compare/9333ca7...23aa7da

Re: Composer – Disable GC when computing deps and refs

#24

Post by icebraining »

Maken wrote: post #20
Mithaldu wrote: post #13

As far as i understand composer is roughly the same thing as the cpan client. And they just simply disabled the garbage collector for it. What is this guy doing that he needs gigabytes of memory to install a bunch of php libraries? Before: Memory usage: 2194.78MB (peak: 3077.39MB), time: 1324.69s After: Memory usage: 4542.54MB (peak: 4856.12MB), time: 232.66s

So, did they exchange a 70% reduction in execution time for a 100% increment in memory usage?

In that particular case; other reports on that thread show much better reductions in time for much lower increases in memory.

Re: Composer – Disable GC when computing deps and refs

#25

Post by icebraining »

rossriley wrote: post #22
DangerousPie wrote: post #12

Interesting. I was looking at the comments hoping for some more technical background, but unfortunately they seem to have been run over by the animated gif crowd. Any more details on this?

It seems when you start to hit the memory limit PHP's automatic garbage collection will loop through the constructed objects to see if any can be cleaned up. If none can (and in the case of Composer all the objects exist for a reason) then it's wasting time analysing the objects. So in this case there's only a large waste of cpu doing nothing with gc enabled.

Well, yes and no, since some of the reports show an increase in memory usage, so the gc was doing something.

Re: Composer – Disable GC when computing deps and refs

#26

Post by bshimmin »

benihana wrote: post #11

The commit is great. I love that the comments have spiraled completely out of control. At this point, 30 minutes after the link was posted, the comment thread is now a competition to see who can post the best gif. I know we're serious here, but stuff like this reminds me why I love the internet so much. It's fun to cut loose once in a while.

Agreed. It's such a shame that HackerNews doesn't let you post animated GIFs - I think it'd really add a lot of value to the discussions here.

Re: Composer – Disable GC when computing deps and refs

#27

Post by debacle »

Mithaldu wrote: post #13

As far as i understand composer is roughly the same thing as the cpan client. And they just simply disabled the garbage collector for it. What is this guy doing that he needs gigabytes of memory to install a bunch of php libraries? Before: Memory usage: 2194.78MB (peak: 3077.39MB), time: 1324.69s After: Memory usage: 4542.54MB (peak: 4856.12MB), time: 232.66s

That user is using PEAR, which is the old shitty PHP "CPAN"

That's the reason for the huge memory usage. We're slowly moving away from PEAR, but since it works for now not everyone has/will transition.

Edit: I should also point out that there are a few packages that almost everyone uses (PHPMD, PHPCS, phpUnit) that are still mostly pulled from PEAR, though I think phpUnit has a composer option.

Re: Composer – Disable GC when computing deps and refs

#28

Post by innocenat »

jcampbell1 wrote: post #21
dec0dedab0de wrote: post #10

Could someone more versed with PHP, and this project explain why turning off garbage collection helped so much? and why they didn't turn it back on at the end of the function?

PHP is reference counted, so memory is typically freed as soon as an object is no longer needed. Cycles are the exception which can cause memory leaks, so in version 5.3 php added a cycle collector, which reads every object in memory and very occasionally deletes objects that are disconnected and have greater than zero reference counts (cycles). In my opinion, the php cycle collector is a pointless waste of time. In…

I agree that cycle collector is pointless waste of time. Most script runs short enough that the memory leak doesn't really matter.

But for long running script, it's either cycle collector, or add support for weak reference. But IMO, due to how reference are stored in PHP, and to my limited knowledge of PHP core, I am quite sure cycle collector are more beneficial in both developer time and usefulness. (Not every programmers know how to manage reference cycle)

Re: Composer – Disable GC when computing deps and refs

#29

Post by [deleted] »

benihana wrote: post #11

The commit is great. I love that the comments have spiraled completely out of control. At this point, 30 minutes after the link was posted, the comment thread is now a competition to see who can post the best gif. I know we're serious here, but stuff like this reminds me why I love the internet so much. It's fun to cut loose once in a while.

[deleted]
Post reply on HN