Hi,
Yes I'm using Symfony 1.2.7 with Propel 1.3, which seems to be bundled
with symfony now, correct? I'm not sure how to check the version of
Propel other than looking at the version number written in the source
code:
const VERSION = '1.3.0-dev';
I'm a little miffed about a common definition of "garbage collection"
here. There are several sites that describe how PHP frees up memory.
Are you saying that PHP does not clean up any memory until the script
finishes executing?
In terms of the many extra objects Propel creates - do you know of any
analysis that describes what these objects are?
The heart of symfony code which calls propel seems to be in the
sfPropelData class. I see this code contains everything in a single
transaction in the loadData method, and then each file's contents are
kept in memory in the loadDataFromArray method.
I was wondering if we might also be able free up some of these Propel
objects by not containing the entire load-data procedure in a single
transaction?
Cheers,
Steve
On Jun 10, 4:04 pm, Fabian Lange <[email protected]>
wrote:
> Hi, no you are wrong.
> Propel internally builds up a lot of objects that reference each
> other. It has nothing to to with tables referencing each other.
>
> And I wouldnt call that PHP GC a garbarge collector
>
> Are you using propel 1.3? It is much friendlier with respect to memory
>
> Fabian
>
> On Jun 10, 2009, at 9:26 PM, Steve Sanyal wrote:
>
>
>
> > PHP does have a "garbage collector", but this may be an issue with an
> > inability to perform gc due to a circular reference issue in Propel.
> > If I understand it, the problem happens in this kind of case:
>
> > Table A has a reference to Table B, thus the propel om has classes A
> > and B, which have references to each other.
>
> > Let say you something like:
>
> > $a = new A();
> > $b = new B();
> > $a->setB($b);
> > (under the covers, $b will now also have a reference back to $a)
>
> > Once $a and $b go out of scope they should be marked to be freed up by
> > the garbage collector. But I think what happens is that when the
> > garbage collector sees $a it sees that $b has a reference to it, and
> > vice versa. So neither gets unallocated. I saw that the propel folks
> > did some work on this, but I haven't gone through their code.
>
> > This may also be an environment related issue. I have had the same
> > dataset working for months on Vista, on my laptop where I've been
> > developing my app. My phpinfo() on Vista says max memory is 128M, the
> > same as the Linux box of my hosting provider. I never had any
> > problems until I tried this on Linux, and even on Linux it's
> > intermittent.
>
> > I also see the provider is running PHP 5.2.9, whereas I'm running
> > 5.2.8 on my laptop.
>
> > Cheers,
> > Steve
>
> > On Jun 10, 2:53 pm, Fabian Lange <[email protected]>
> > wrote:
> >> The problem is that PHP has no garbage collector. Once allocated all
> >> propel objects stay in memory.
> >> And propel has tons of them.
> >> The last time I had to load I built my load script by hand, squeezing
> >> out everything which was not needed
> >> I set the limit to 1gb and after a long time i could import it.
> >> Other solutions are to split the import into multiple command line
> >> invokations. But this will only work as long as you do not have a FK
> >> relation between the objects
>
> >> Good luck
>
> >> Fabian
>
> >> PS: ORM is not the right tool for data dumping, and loading or
> >> migration
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---
