[rkward-devel] limiting onscreen graphics history

[Thomas Friedrichsmeier]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20100630/a3b725e3/attachment.sig>