| Thread Previous • Date Previous • Date Next • Thread Next |
On 2011-05-04 08:32, Gavin Panella wrote:
One approach to improving this situation could be to forbid (with code) the use of Reference properties that are not already cached (in the store cache; this is nothing to do with @cachedproperty).
I'm a bit worried about the unusual cases: rarely-executed code paths, unusual data, data that is usually cached but sometimes isn't, data that falls out of the cache at an awkward moment.
If we block reference demand-loading, we start taking oopses for those situations. And if we then fix those oopses by doing more eager loading, we may end up taking an unnecessary performance hit and pay for it in extra code complexity.
Wouldn't a logging-and-monitoring approach be preferable over a blocking-and-fixing approach here? I haven't had time to work on my Storm profiling branch lately, but it would let us track which references lead to how many new objects being fetched, coming from how many other objects. With information like that we could make rational tradeoffs between eager and on-demand fetching.
Jero
| Thread Previous • Date Previous • Date Next • Thread Next |
