<br><br><div class="gmail_quote">On Mon, Jun 11, 2012 at 10:01 PM, Fernando Perez <span dir="ltr"><<a href="mailto:fperez.net@gmail.com" target="_blank">fperez.net@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 class="im">On Mon, Jun 11, 2012 at 9:54 PM, MinRK <<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>> wrote:<br>
> I'm 50-50.  I generally think of NoDB as an optimization, which would<br>
> suggest that *it* should be the optional case for people in the know, rather<br>
> than the other way around.<br>
<br>
<br>
</div>I guess what we're finding is that it can cause a pretty nasty failure<br>
mode with fairly naive and natural use patterns.  </blockquote><div><br></div><div>Yes, there is cost to storing large amounts of data.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Alternatively, would<br>
it be possible for the dictdb to (at least by default) drop every<br>
result that gets retrieved?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> That would keep the ability to do delayed<br>
retrieval while perhaps lowering the memory pressure under common use<br>
patterns.<br></blockquote><div><br></div><div><div>What do you mean by retrieved?  Under the normal circumstances you described, exactly zero results are retrieved from the Hub, so this would have no effect other than breaking delayed retrievals after the first.</div>

<div><br></div><div>Remember, the Hub is not involved *in any way* in the results of basic execution/reply, and it can be removed entirely with no effect whatsoever on simple executions.</div><div> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="im"><br>
> I don't view delayed result retrieval as "advanced", but I think has turned<br>
> out to be rare, so I would be okay with this.  The one thing it changes is<br>
> adding big warnings to the docs, because a huge swath of features would be<br>
> totally unavailable by default.<br>
<br>
</div>I'm not saying I'm too happy with the idea, but my experience today<br>
has made me lean towards it more, thinking of 'regular' users...<br></blockquote><div><div><br></div><div>I know, it makes sense.  </div><div><br></div><div>Another option could be for DictDB to have a finite history, and just dump old results if it has too many.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="HOEnZb"></div></blockquote></div>
<div>
It's also widely varied - If each task sends/receives 10MB arrays, it only taks a few hundred to be a problem.  If, on the other hand, it's mostly simple commands without large data or side effects, it takes millions before there is an issue.  This makes the above suggestion difficult, because for some users a history of 100 is huge, while for others it's tiny.</div>

<div><br></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"><br>
f<br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br>