Re: Re[4]: [PEAR-DEV] Package proposal

From: Date: Tue, 12 Oct 2004 14:02:55 +0000
Subject: Re: Re[4]: [PEAR-DEV] Package proposal
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-33802@lists.php.net to get a copy of this message
> No, you are wrong. Caches are located not on clients' machines. There > are no several copies of cache. All clients use one cache. As I saw, you define a store_dir and read/write to it - but it's not a remote directory, i.e. connecting to remote server and read/write there (from network traffic point of view it would be even worst than db caching). So we have multiple caches - one per each "web server". > Yes i can not. But why it bother you :) Common script user usually do > not modifies data directly through phpMyAdmin. It just sets up > application and runs it. If you are not common user and you modified > data bypassing caching mechanism you can just delete cache from disk. > That is all you need to invalidate all cache :) Probably the common user doesn't know what is query caching at all, so this topic is dedicated for experienced users and performance critical cases. :) > :)) Yes, idea is good. To be more specific, i need use not regexps (As > they allow describe only language with finite state grammar) but > context-restricted grammar analyzer. But the main point of cache is > speed, so i implemented most simple and fast way. We can treat it as > limitation: "All table names should be unique among other SQL > entities". Well, if I want speed so much, I'll use the core C API, not some abstraction layer. Regular expressions are not soooo slow...:) Actually you can take a look at http://pear.php.net/package/SQL_Parser > I want to say that this is not ideal caching solution and it has some > restrictions and disadvantages. But it can be useful, at least it is > useful for us :) O.K. I agree that it could be useful in *some* cases. Anyway, the user is free to decide to use or not to use it. But as is the situation with browser caching, we could have unexpected behaviour and hard feelings among users - so all the restrictions and disadvantages have to be well described and analyzed. Do you have already performed some benchmarking on that caching versus the MySQL's one? Regards, Kouber Saparev

« previous php.pear.dev (#33802) next »