On 19 Sep 2002 at 10:13, Jim Starkey wrote:

> At 07:20 AM 9/19/02 -0400, Paul Schmidt wrote:
> >
> >
> >It would seem to me, that we could cache the compiled statements, and
> >simply empty the cache when a DDL statement gets executed or the
> >database is
> restarted.
> >However saying that I have run big complex queries that prepared in
> >under
> .1 sec,
> >so caching the prepared statement might save .01 sec per query, and
> >the
> safety of
> >not having to compare almost identical statements and goofing it up,
> >isn't
> worth the
> >time saved, or the memory used to cache the results.
> >
>
> First of all, thanks for the complement. I spent a lot of time
> making the compiler fast. The problem is that the compiler
> is memory allocation intensive. In simple classic, that is
> no problem because I also sweated blood to make the memory
> allocated fast. In a threaded world, however, the memory
> heap must be protected with a mutex that must be siezed and
> released on every block allocated. What works nicely for
> classic can become a hog in a threaded environment.

Would it be possible for a compile to start, allocate a big hunk from the heap, then
unlock the heap, and subdivide it's hunk to do what it needs?

> It isn't necessary to do a fancy tree walk to find almost identical
> statements. Do a string compare (after a hash lookup) for absolutely
> identical. Keep a list of referenced tables with each compiled
> statement to re-validate privileges and allow cheap invalidation after
> a meta-data tweak. But the payback is limited unless the cache can be
> shared over many attachments. (And, yes, Netfrastructure has this
> optimization.)

I wonder though if nearly identical, really are identical, for example the following two
are actually identical.

SELECT ZNOG_ID FROM ZNOG WHERE ZNOG_ID = 23456
SELECT ZNOG_ID FROM ZNOG WHERE ZNOG_ID = 23457

Now you might gain a lot by doing a substitution, where the above both get stored
and compared as:

SELECT ZNOG_ID FROM ZNOG WHERE ZNOG_ID = ?

However at some point the SQL gets complex enough that it needs to store them as
they are, and possibly even give up trying to cache a big complex statement, but
those are the statements that could benefit the most from not having to re-compile
ad nausium.

> >
> >The question with a single multi-threaded process, is that will an
> >SMP
> machine be
> >able to run different threads on different CPUs? If so, what's
> >holding
> SuperServer
> >back, from being able to do that now?
> >
>
> In Linux threads are implemented as separate processes sharing
> a single virtual address space. They definitely get scheduled
> on different processors. If you think writing fine granuality
> code is hard, making it scream on a multi-processor is a gas.
>

So on Linux, thread or process is really the same difference, but on Windows which
benefits more with threads, threads are wierdly complicated..... I tried writing a
multi-threaded Windows app, but it ended up effectively one thread, because #@$!^
Win9x can't figure out how to answer a modem when it rings....

Paul Schmidt, President
Tricat Technologies
paul@...
www.tricattechnologies.com