Re: [Cronometer-development] speed

[Chris R. <of...@gm...>]

I think that's a good idea, at least it sounds like one.  Since we're
dealing with an embedded DB, this should be reasonably workable.

One other thing we should do, as we move towards a beta, is design ye
olde website.  SF will host it, assuming we have simple needs, and we
can move it later if we get more complicated.

On 5/28/05, Aaron Davidson <ada...@po...> wrote:
> Did a little snooping on the slow speed -- It's definately just the
> food loading. It gets worse and worse as you add more and more foods to
> the daily list. It has to load each one from the database every time it
> is needed. Adding a food to the day forces all foods in that day to be
> reloaded from scratch.
>=20
> We could cache loaded foods in a WeakHashMap, and always check it
> before loading. Just need to make sure it is *always* checked first, so
> that read/write stale cache conflicts don't occur. What do you think?
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22=
005=20
> _______________________________________________
> Cronometer-development mailing list
> Cro...@li...=20
> https://lists.sourceforge.net/lists/listinfo/cronometer-development=20
>=20


--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.