Hi, On Wed, Jun 30, 2010 at 6:20 AM, Thomas Friedrichsmeier <thomas.friedrichsme...@ruhr-uni-bochum.de> wrote: > Hi, > > On Wednesday 30 June 2010, Prasenjit Kapat wrote: >> 1. Limit on L, no limit on either S or s -- naive >> 2. Limit on L and s which in turn limits S as well -- better than 1 >> but the user may not have a clear idea of how large s can be? 1 KB? 5 >> KB? 30 KB? >> 3. Limit on L and S -- can be easily superseded by just limiting on S. >> 4. Limit on S -- seems reasonable >> 5. Limit on S and s = p * S where p = (say) 0.6 -- more reasonable. > > I'm somewhat undecided between 2 and 5. 5 is most elegant, technically, but 2 > may be slightly easier usability-wise. I think it depends on what we believe > how what would be sensible values for L, s and S. For L, I believe the ~5-10 > most recent plots are the most interesting by far, but we could assume 20 to > be on the safe side. > Regarding s, the object.size() of plot(rnorm(100000)) is around 1.6MB, here. > So, if we set s to 2MB, that should support pretty much any plot in practice. > Multiplying that in solution 2 would yield 40MB. That *is* pretty large. On > the other hand, S would _typcially_ be much smaller in solution 2, and on > systems where 40MB are a serious issue, RKWard may not be a good choice in the > first place. > In solution 5, memory-usage would always approach S after extended usage, so > it may be reasonable to set S somewhat lower, perhaps at 10MB. > > How large is a "typical" plot? My guess is 50KB. That would mean 200 plots can > be stored in 10MB for solution 5. For solution 2 that means the typical memory > use for the plot history is 1MB. > > Hm, ok, after writing this down, I think I'm inclined towards solution 2.
Thanks for the numbers! If no one has any objection, then I shall implement 2 shortly. >> Along with these, the toolbar >> icons have to be updated accordingly. These will not be difficult to >> implement, but I am just wondering about the overhead cost, if any! >> >> If the number of managed devices is small (which it is, in my personal >> usage - 3 or 4 max) then the cost will be minimal. But if, it >> increases to 10 or 15, then I am not sure of how much overhead cost >> this will create. (Recalling the thread on performance: >> http://thread.gmane.org/gmane.comp.statistics.rkward.devel/784 , >> although I am not sure if anyone would have 10 or 15 or more onscreen >> device windows open at the same time.) > > I wouldn't worry about this too much at this point. I've just tried opening 30 > devices, and then calling rk.record.plot$.rk.graph.history.gui(). The command > did not take a noticable amount of time, here. I can improve .rk.grapch.history.gui () marginally so that not all the devices need updating when browsing through history. > Probably it does take a couple milliseconds, but the difference between this > situation and the one in the performance thread is that there the overhead can > occur inside a loop (i.e. thousands or millions of times in a row). In > contrast, here, the overhead occurs once for certain actions (adding a new > device/plot, etc.). These actions will typically not occur in a loop, but > rather on user interaction, and they are already associated with rather > expensive computations such as creating a plot. Thus the overhead is simply > not practically relevant at this particular point. Good point, I thought so as well. Regards, -- Prasenjit ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
