[rkward-devel] limiting onscreen graphics history

[Prasenjit Kapat]

Hi,

On Wed, Jun 30, 2010 at 6:20 AM, Thomas Friedrichsmeier
<thomas.friedrichsmeier at 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