[EMAIL PROTECTED] wrote: > thanks for your reply > > i'll try unset, and see if that helps > also, i know the problem is in that code i posted, because if i comment > out the pel stuff, the memory that is used doesn't accumulate in the same > way > for example, > > with pel code, after doing an image resize, using memory_get_usage() > 3000 KB after first image > 3500 after second image > 4000 > 7000 > 11000 > and so on, > > but without the pel code, it looks more like > 3000 > 3010 > 3005 > 3020 > 3020 > 3010 > 3020 > the memory usage doesn't go up significantly > > i'm pretty sure it has something to do with writing the file three times > in that one function > do you know of a better way to get the exif data, write the jpeg using gd, > then write the exif data back to the jpeg? > > i'm going to experiment with removing one of the file writes, just to see > how it affects memory tonight, but i can't really see how it can be > reduced to one file write > hmmm.... i basically tested it with just opening the original file with pel, then closing it using unset and writing the image using imagejpeg basically $origJpeg->loadFile($fullFilePath); $exif = $origJpeg->getExif(); unset($origJpeg); imagejpeg();
and it still ran out of memory, did a few more images, but was still less than 10 seems like file_get_contents doesn't work nearly as well as one would hope > if worse comes to worse, i may have to save the exif data to db or > something and put it back later, in a different process > > thanks > dave > > On Wed, November 22, 2006 7:44 pm, Martin Geisler wrote: > >> dave <[EMAIL PROTECTED]> writes: >> >> Hi Dave >> >> >> >>> hmmm... doesn't appear to be pel or anything like that seems that my >>> image resources aren't being completely freed or something and the >>> memory usage accumulates, until it crashes >>> >> That's strange. I haven't tried processing multiple large images in a >> single script with a memory limit before, so I haven't seen the bug before. >> >> >> PEL don't know anything about file handles, image resources, or >> similar stuff that would consume resources, so I don't see how it should >> leak memory. >> >> It does have a few static variables in Pel.php which could fill up. >> I'm thinking of Pel::$exceptions which is an array of exceptions which >> have been suppressed when parsing. Try calling Pel::clearExceptions() once >> you are done with each image -- maybe that will help. >> >> >>>> i'm using gd to resize my images, and pel to re-attach the exif data >>>> after gd has finished but i've run into a problem with the memory >>>> limit >>>> >>>> i'm using php 5.2.0 on fedora core 4 pel is updated via svn from trunk >>>> >>>> >> Good! >> >> >> >>>> [...] >>>> >>>> >>>> the offending code is [...] >>>> >>>> $origJpeg->loadFile($fullFilePath); >>>> >>>> >> Good, this uses file_get_contents() to load the file in one big swoop. >> The PHP manuals says that this is "the preferred way to read the >> contents of a file into a string. It will use memory mapping techniques if >> supported by your OS to enhance performance." >> >> Unfortunately file_get_contents() doens't seem to work quite as good >> as promised by the PHP documentation: see SF bug #1210126 where someone >> suggested that PEL should read the data from the files as needed. I >> thought that file_get_contents() would work that way since it memory maps >> the file. >> >> >>>> $exif = $origJpeg->getExif(); >>>> >>>> >>>> [...] >>>> >>>> >>>> $newJpeg = null; >>>> } >>>> $origJpeg = null; >>>> >>>> >> There might be a difference between assigning null to the variables >> and calling unset() on them. >> >> >>>> i am using imagedestroy, that is in another section of the code that >>>> is not visible here >>>> >> Okay good, that would have been my next question :-) >> >> >> -- >> Martin Geisler --- <[EMAIL PROTECTED]> --- http://mgeisler.net >> >> >> Read, write, create Exif data in PHP with PEL: http://pel.sf.net >> Take control of your webserver with PHP Shell: http://phpshell.sf.net >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your opinions on IT & business topics through brief surveys - and earn >> cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> PEL-devel mailing list >> PEL-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/pel-devel >> >> >> > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PEL-devel mailing list > PEL-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pel-devel > > -- http://dtracorp.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ PEL-devel mailing list PEL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pel-devel
