tag:blogger.com,1999:blog-7301919772901781969.post1623192399026119336..comments2024-03-27T07:56:45.589-07:00Comments on Noda Time: Performance mattersJon Skeethttp://www.blogger.com/profile/09730219126872960482noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7301919772901781969.post-83673720316174338342010-03-16T08:49:57.916-07:002010-03-16T08:49:57.916-07:00Awesome stuff, Jon! I can't wait for v1.0.
Ke...Awesome stuff, Jon! I can't wait for v1.0.<br /><br />Keep up the great work.<br /><br /><br />Cheers,<br /><br />CharlesCharles Strahanhttps://www.blogger.com/profile/04027286025058393036noreply@blogger.comtag:blogger.com,1999:blog-7301919772901781969.post-9415624569427979702010-02-23T04:09:57.794-08:002010-02-23T04:09:57.794-08:00"so long as most of your uses fall within the..."so long as most of your uses fall within the same 50 year period, you're very likely to hit the cache too"<br />I've noticed most apps that use times massively are either calendar-y, normally using dates in a time period of a few years, or lifetime-y, using dates in a 80-100 year period (consider date of birth and date of end of a savings or pension plan for example). Which is why 50 seems to me like a completely wrong number. I think the cache should be optimized to either be useful for about 10-20 years, or for about 100 years. Or, it can have a dynamic cache size with suggestions in the docs for 10-year and 100-year values.configuratorhttps://www.blogger.com/profile/14918283630192202333noreply@blogger.com