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. > 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. 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. Regards Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
