> From: Alexander V.Nevsky
> To: firebird-support@yahoogroups.com
>
> --- In firebird-support@yahoogroups.com, "Jerome Bouvattier"
> <JBouvattier@I...> wrote:
> > Hi again,
> >
> > Does anyone have a clue about this ?
> > Is this a known issue ?
> > Maybe I should ask in devel ?
> >
> > Note that cache isn't involved here. Restarting FB doesn't change
> the SP's
> > execution speed, be it in a fast or slow scenario.
>
> Jerome, IMO this is still cache effect. Subsequent execution of any
> statement always is much faster - first execution fills the cache with
> pages needed for this statement and subsequent one don't access hard
> drive or make it in much less degree.

Thank you very much for you help Alexander,

You must be right. I reboot the server machine, and I can observe the slow
down again. So GC is not the culprit, it probably just left cache in a state
that was useless for my statement. Hence my misinterpretation.
What is new to me is the fact that simply shutting down and restarting FB
service is not enough to exclude the cache as a role player. Apparently, a
subsequent execution of FB process can benefit, in some conditions, from the
memory state left by the previous instance. There is something I don't get
here. The cache does not survive FB shutdowns. Right ?

- Start FB
- Execute SP : 6s
- Execute again : 820ms
- Execute again : 820ms
- Shutdown/restart FB
- Execute SP : 820s !! Where does the cache come from ?
- Reboot server OR Select count(*) OR Sweep OR Restore
- Execute SP : 6s
- Execute again : 820ms
- Execute again : 820ms

Best Regards.

--
Jerome