Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Future as a FoxPro Developer
Message
De
12/07/2004 23:14:19
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00918302
Message ID:
00923532
Vues:
35
John,

I've read tons on cache over the years. I feel comfortable that I have a reasonable grasp of the subject.

Now why would I say what I said... because the standard MS "strategy" of maintaining compatibility across all (supported) OSes actually hamstrings them, at least to some degree, when it comes to cache 'manangement'. For example, Win98SE systems with 8MB, 16MB or 32MB RAM were perfectly legitimate and widely installed. Such systems likely also have HDs with only rudimentary capabilities compared to todays. Etc.

Essentially the constraints imposed on the cache/redirector/lock mechanisms as a result cannot be "optimal" by any stretch. Remember, all that stuff HAS to be coded for the least system so that becomes the 'base' capability for all of it.

Now I see .NET as (probably) "relieving" that situation. It is not unreasonable to 'impose' significantly higher system requirements for Win98SE systems that want to run .NET applications, particularly are regards reasonably cheap RAM and HD speed/capacity. Hell, you can buy a whole new well-configured system for what the RAM itself cost in Win98SE's heyday. A new system ($399.) with 256MB and a cached 40GB HD can still run Win98SE but now it can do a credible job with .NET.

But this would mean that it would be with .NET that exploitation of such stuff would have to be delivered.

A simple bit of logic, really, that holds up well in my eyes.

What do you see wrong with it?

UPDATE: I've just started reading your reference and I've got to say it's not very useful as a true "primer". Maybe useful to explain away some .NET access things, but not enlightening as a "primer". But I will finish it regardless.

Jim

>>
>One can easily imagine the need to seriously tweak cache management in a .NET environment given the way data access works there. I wonder if it's specific to .NET applications or general across the OS.
>>
>
>Why is that? Certainly, there are strategies on when you would use the cache to store data. But...that is an entirely different thing that "tweaking" the cache.
>
>A good primer can be found here:
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/CachingArchch1.asp
>
>Lots of good material. Of course, that is what you get when innovation is front and center.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform