Subject | Re: Performance penalty if using threads? |
---|---|
Author | Adam |
Post date | 2008-11-10T02:27:15Z |
--- In firebird-support@yahoogroups.com, "maverickthunder"
<maverickthunder@...> wrote:
executing anything. I am guessing that slowness can be explained by
* Synchronisation delays between your worker thread and main thread.
* Different thread priorities given to main thread and worker threads.
* Serialisation delays if you share connections etc between threads.
That said, I can imagine a select being slow under such situations,
because it must wait for your application to request the next chunk of
data, but this is not the case for inserts, updates and deletes.
You do however need to take care when performing this test. Bulk
deletes etc will cause garbage to accumulate, and the cleanup of this
garbage may be polluting your observations.
In another scenario with threads where you have multiple worker
threads each performing their own operations independently, you may
encounter hardware bottlenecks (disk thrashing) and lock conflicts
that may slow down overall throughput when compared to a single thread
application, but this does not sound like your case.
A significant portion of our software relies on multi-threaded
connections to the database (1 connection per thread model), and we
have observed no performance impact compared to executing the same
queries in the main thread.
Adam
<maverickthunder@...> wrote:
>I doubt that Firebird particularly cares what thread in your PID is
> Hi,
>
> My home computer is a Pentium 4 @ 1800mhz with 1.5gb ram. I made an
> app that run a background thread that download data from the web and
> stores them in a firebird 2.1.1 db. The main thread is almost idle
> because it only processed gui events.
>
> I noticed that if I move the process to the main thread, the queries
> (insert, update and select) are faster.
>
executing anything. I am guessing that slowness can be explained by
* Synchronisation delays between your worker thread and main thread.
* Different thread priorities given to main thread and worker threads.
* Serialisation delays if you share connections etc between threads.
That said, I can imagine a select being slow under such situations,
because it must wait for your application to request the next chunk of
data, but this is not the case for inserts, updates and deletes.
You do however need to take care when performing this test. Bulk
deletes etc will cause garbage to accumulate, and the cleanup of this
garbage may be polluting your observations.
In another scenario with threads where you have multiple worker
threads each performing their own operations independently, you may
encounter hardware bottlenecks (disk thrashing) and lock conflicts
that may slow down overall throughput when compared to a single thread
application, but this does not sound like your case.
A significant portion of our software relies on multi-threaded
connections to the database (1 connection per thread model), and we
have observed no performance impact compared to executing the same
queries in the main thread.
Adam