Timeline for What is the point of Refresh if Dynamic has an UpdateInterval option?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 19, 2018 at 21:46 | comment | added | kkm mistrusts SE | @RolfMertig, I am necromancing. but you aren't comparing in Apples^2. Refresh is a HoldFirst, and that's the overhead, it unwraps twice every iteration inside the Do. Leverage that: use =, not := in the definition with Refresh. noRefr[x_] := x^3; withRefr[x_] = Refresh[x^3, None]; RepeatedTiming[Sum[withRefr[i^2], {i,10^6}]]/ RepeatedTiming[Sum[noRefr[i^2], {i,10^6}]] returns the perfect match {1, 1}. in each case, one Hold*[] is unheld inside the Do. In this sense, Refresh[] adds exactly zero computiational overhead. (tested in 11.3). With the := I repro your 1.28 slowdown. | |
| Jul 19, 2018 at 21:43 | comment | added | kkm mistrusts SE | @AlbertRetey, thanks, you are right, my bad, sorry! I'll delete my comment and re-post it exactly tagging the correct user. | |
| Oct 20, 2015 at 8:43 | comment | added | Szabolcs | Could you please take a look here? If anyone, you would know if the definite answer is "no, it's not possible". | |
| Oct 19, 2015 at 9:26 | comment | added | Albert Retey | @Kuba: good points, absolutely helped me to understand that example better. I aggree that other names probably would have made that easier to understand, but that seems to depend on the users mindset: I would probably have got it at first read with abstract names like memoizingKernelFunction for memoize and guiHelpWrapper for f. Anyway, now John's example has convinced me that this is a very good if not the best pattern to solve such issues ... | |
| Oct 19, 2015 at 7:23 | comment | added | Kuba | @AlbertRetey Moreover you can export/share Kernel functions memoize and friends with others without worrying about useless (harming) Refreshes hanging around. At least, this is what I got from the answer. Abstract names in this case are not helping understanding and I still think documentation example is very bad. | |
| Oct 19, 2015 at 7:23 | comment | added | Kuba | @AlbertRetey I think I got this example and if so better names would help future readers. Like: memoize->myThemePlotWithHeavyComputation and f->tabPlotsFromMainTabView, where the former is the Kernel function that, what was my concern too, doesn't have to be wrapped in Refresh "just in case". However the latter is specific package symbol related to package GUI where Refresh makes sense, it would be there because of specific reason, not just in case. | |
| Oct 8, 2015 at 17:57 | comment | added | Albert Retey | @JohnFultz: Am I correctly understanding that whenever you can't avoid side effects in a function (which one of course should avoid where possible) AND you expect it to be used in Dynamic then you would recommend to use a Refresh in such a function as shown? Is the developer/user responsibility really the only relevant difference between my TrackedSymbols approach? | |
| Oct 8, 2015 at 14:28 | comment | added | Rolf Mertig | @JohnFultz Thank's for the clarification. Though I am still confused as to why a kernel-only function should ever worry about the FrontEnd. I just do not use this design pattern and still can use kernel memoization just fine. | |
| Oct 8, 2015 at 14:06 | comment | added | John Fultz | @RolfMertig, Refresh is not widely deployed in v10. It is deployed where necessary. Your speculation about widespread slowdowns, if warranted generally, is not applicable to a connection with Refresh specifically (particularly since v10 has nothing new in regards to Dynamic). | |
| Oct 8, 2015 at 14:05 | comment | added | John Fultz | @AlbertRetey, I'm talking about a situation where a developer is making f available for your use by users. If I don't have end-to-end control, then I have to anticipate any usage. It's not reasonable for me to tell users to hack around my problems. That having been said, this certainly does not arise in many functions. Functions developed with no side effects (which is quite a lot of them) won't exhibit this behavior. For example, in 10.0.0, there was an infinite Dynamic triggering bug in GeoGraphics. The solution finding the accidental side effects and removing them, not Refresh. | |
| Oct 8, 2015 at 8:54 | comment | added | Rolf Mertig | @AlbertRetey the overhead is about 25%. Check: RepeatedTiming[Do[ Refresh[i^2, None], {i, 10^6}]][[1]]/RepeatedTiming[Do[ unfresh[i^2, None], {i, 10^6}]][[1]] Maybe this explains the slowdown of 15-30% in pure kernel operations from Mathematica 9 to Mathematica 10 ? | |
| Oct 8, 2015 at 8:23 | comment | added | Albert Retey | I have used an explicit TrackedSymbol:>{f} option for the Dynamic[Refresh[counter++,None];f[20]] in such cases which seems to achieve the same behavior. Can you explain what the advantage of the Refresh approach is? I find it somewhat problematic that the author of f has to take care of a Dynamic not refreshing which might make use of f which he probably not even knows about when he originally wrote f (hasn't that situation occured at WRI?). What is the overhead of such a Refresh, would you recommend to generally use such Refresh wrappers just in case of? | |
| Oct 8, 2015 at 7:59 | history | answered | John Fultz | CC BY-SA 3.0 |