Possible memory leak?
Tuvas
tuvas21 at gmail.com
Tue Jan 24 20:41:28 EST 2006
More information about the Python-list mailing list
Tue Jan 24 20:41:28 EST 2006
- Previous message (by thread): Possible memory leak?
- Next message (by thread): Possible memory leak?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hmm. The problem is that the required form for the image is as a string of characters to convert with the tkimage interface, at least, as I understood it. Perhaps an array would work, I'll try that when I get ahold of the computer in question (One thing required is a linux only library, and I don't have access to a linux machine at the moment...) However, I would like to make a few more statements. The max image size is 1024x1024. The length of time it takes to do the row statement increased fairly substationally every time it was ran, in the order of ~.5%. That seems small, but when you run it 1M times, the last operation will take 5000 times longer than the original, or about ~1sec. And that's just for one row, the entire process would take an eternity... And the real kicker, when doing this with smaller images, ei, about 128x128, the second image starts of at the same point of slowness as the first one. EI, the last operation of the first image took .01 seconds to complete (It started, let's say, around .005), for instance, the next one would start at that length of time, and end at .02 or so, the third picture would be taking that long for each row, and so on. It only does this on one particular computer (I've only had the chance to run it on 2 machines to date, BTW.) There is a reason why the rows are pieced together as is, I must say, but it's a tad bit complicated... I'll just defend it without giving a real reason. Thanks for the help!
- Previous message (by thread): Possible memory leak?
- Next message (by thread): Possible memory leak?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list