<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:#3d85c6"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 9, 2014 at 6:08 PM, Matthew Bell <span dir="ltr"><<a href="mailto:matthewrobertbell@gmail.com" target="_blank">matthewrobertbell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You were right, my code was lazily thought out. With one query (with one subquery), the execution is fast and memory consumption normal.<br><br>Thanks!<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;color:rgb(61,133,198)">From my own experience I can tell you that Pony caching has never caused me any problems. One note though, if you're using flask or any other program that gives you memoization capabilities like `lru_cache` in Python 3 or `cached_property` werkzeug, be careful when using them since by using them the database objects get <i>stuck</i> and are not marked for deletion later on. Hence your cache can grow exponentially. My advice is this, pony caching is not a problem, caching cached objects however, is.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On 8 November 2014 13:19, Alexander Kozlovsky <span dir="ltr"><<a href="mailto:alexander.kozlovsky@gmail.com" target="_blank">alexander.kozlovsky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi, Matthew<br><br>If you retrieve these objects to render some HTML page, than I doubt that you really need so many objects. I think that a typical web page requires several thousands objects at most, and this amount is not big enough to cause memory problems.<span><br><br>> <span style="font-family:arial,sans-serif;font-size:13px">each time the inner function is called, it returns a data structure full of pony objects (but a lot less pony objects than the function internally used)</span><br><br></span>Ideally you function should retrieve only the objects which are actually required to render the Jinja template. If the function retrieves much more objects, but then uses only small fraction of them, then it probably written inefficiently. You should do object filtering not in memory, but in the initial database query.<br><br>If you can show me the database query then I probably can suggest a better way to do filtering, so only required objects will be materialized in memory.<br><br>Regards,<br>Alexander<br><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 7, 2014 at 5:40 PM, Matthew Bell <span dir="ltr"><<a href="mailto:matthewrobertbell@gmail.com" target="_blank">matthewrobertbell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>I think the problem is that each time the inner function is called, it returns a data structure full of pony objects (but a lot less pony objects than the function internally used). I could pull the attributes of the objects that I need (to inject into a Jinja template, but not for a webapp), but that seems hacky. I could pickle / just return the IDs of the objects, but that also seems hacky.<br><br></div>The relevant line in the jinja template is like:<br><br></div>{% for keyword in keywords %}<br></div> {{ keyword.expensive_method() }}<br><br></div>Do you see any solutions?<br><br>Thanks<br></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On 6 November 2014 13:05, Alexander Kozlovsky <span dir="ltr"><<a href="mailto:alexander.kozlovsky@gmail.com" target="_blank">alexander.kozlovsky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Matthew,<span><br><br>> <span style="font-family:arial,sans-serif;font-size:13px">Does Pony's in-memory cache have a size limit?</span><br><br></span>Currently no, but we can think about it. It may be not so easy to implement, because objects in cache have cross-relations.<br>May be we can add some method like db_session.forget(MyEntity) to clear all unmodified entities of this type from the cache. Can this help in your case?<span><br><br>> <span style="font-family:arial,sans-serif;font-size:13px"> I have a function which does a lot of queries within one transaction</span><br><br></span>Are you sure that in your case all those queries must be done in the same transaction? If not, then wrap different queries in different db_sessions, and old objects should be cleared automatically.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Nov 6, 2014 at 3:43 PM, Matthew Bell <span dir="ltr"><<a href="mailto:matthewrobertbell@gmail.com" target="_blank">matthewrobertbell@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>Does Pony's in-memory cache have a size limit? I have a function which does a lot of queries within one transaction, dereferencing > 99% of the pony objects, but the memory used by the process grows and grows and the function goes through its loops.<br><br></div>Psuedo code:<br><br></div><div>results = []<br></div>for i in range(5):<br></div> results.append(some_function_which_queries_lots(i))<br><br></div>Thanks!<span><font color="#888888"><br clear="all"><div><div><div><div><div><div><br>-- <br><div>Regards,<br><br>Matthew Bell<br></div> </div></div></div></div></div></div></font></span></div> <br></div></div>_______________________________________________<br> ponyorm-list mailing list<br> <a href="mailto:ponyorm-list@ponyorm.org" target="_blank">ponyorm-list@ponyorm.org</a><br> <a href="/ponyorm-list" target="_blank">/ponyorm-list</a><br> <br></blockquote></div><br></div> <br>_______________________________________________<br> ponyorm-list mailing list<br> <a href="mailto:ponyorm-list@ponyorm.org" target="_blank">ponyorm-list@ponyorm.org</a><br> <a href="/ponyorm-list" target="_blank">/ponyorm-list</a><br> <br></blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br><div>Regards,<br><br>Matthew Bell<br></div> </font></span></div> <br>_______________________________________________<br> ponyorm-list mailing list<br> <a href="mailto:ponyorm-list@ponyorm.org" target="_blank">ponyorm-list@ponyorm.org</a><br> <a href="/ponyorm-list" target="_blank">/ponyorm-list</a><br> <br></blockquote></div><br></div> </div></div><br>_______________________________________________<br> ponyorm-list mailing list<br> <a href="mailto:ponyorm-list@ponyorm.org" target="_blank">ponyorm-list@ponyorm.org</a><br> <a href="/ponyorm-list" target="_blank">/ponyorm-list</a><br> <br></blockquote></div><br><br clear="all"><br>-- <br><div>Regards,<br><br>Matthew Bell<br></div> </div> </div></div><br>_______________________________________________<br> ponyorm-list mailing list<br> <a href="mailto:ponyorm-list@ponyorm.org">ponyorm-list@ponyorm.org</a><br> <a href="/ponyorm-list" target="_blank">/ponyorm-list</a><br> <br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><font size="4" face="trebuchet ms, sans-serif" color="#6fa8dc">Kind Regards,</font></div><div><img src="https://brnbcg.blu.livefilestore.com/y1mIyqRuYWMVkEp1XgqnpPJw31rRYoNvXRcLpo1WOUfIx-d9b0krZq2EJ4vUjOgoHcfZow1IZifvV3JxEuWl7yinOPYSMwlrPk7rFfWQ7RMTlkgQ9uTAq0uNQ/Signature1.png?psid=1" width="96" height="69"><br></div><div></div><div><span style="font-family:'trebuchet ms',sans-serif;font-size:large"><font color="#6fa8dc">Quazi Nafiul Islam</font></span></div></div></div> </div></div>