Subject Re: [Firebird-general] ANN: FBTM V3 Screencast - Is Co-operative Garbage Collection causing statement execution slowdown?
Author Thomas Steinmaurer
Hi Ann,

> On Thu, Nov 28, 2013 at 3:41 AM, Thomas Steinmaurer <ts@...
> <mailto:ts@...>> wrote:
>
>
> the same statement with the same execution plan is running much slower
> on different occasions? Co-operative garbage collection in Firebird
> Classic and SuperClassic might be the root cause.
>
> Check out this demo how to get some feedback if garbage collection has
> been additionally performed for an executed statement:
>
> http://www.iblogmanager.com/download/demos/fbtm/fbtm_30_garbage_collection.htm
>
>
> Err ... sure, running with co-operative garbage collection makes the
> cost of
> garbage collection show up in the cost of running a statement. But the
> actual
> cost of garbage collection is about the same for co-operative and
> thread-based
> methods; the difference is that the thread-based doesn't show up as the cost
> of a user's statement. In a single user system with long pauses between
> statements, the thread-based garbage collector is a big win because it runs
> in the pauses. In a heavily loaded system where there is little or no
> idle time,
> the thread-based collector competes with useful work.

Yes, I know.

The reason why it is IMHO worth to expose that behavior more prominent
to the public, beside being a plug for our product *g* and the Trace API
is, that performance issues are more interesting when end-users are
directly affected, which is the case for co-operative GC due to GC being
processed synchronously to the executed client request.

And it is good to know have something in the toolbox to identify
possible execution time degradation caused by GC. But you all know that. ;-)

> As you know, when Firebird executes a delete statement, it actually creates
> a new short version of the record called a deleted stub. Once the delete is
> mature - meaning that no transactions expect to read the records that have
> been deleted - both the stub and the original version are removed. So the
> select count(*) does more work than the delete that preceded it.
> One question is why you had to disconnect to force garbage collection...

Database Workbench resp. used data access component thingy, basically
having a transaction and/or statement handle open behind the scene.



--
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.