New approach for gbak – significant performance improvements

[Adriano dos Santos Fernandes]

Hi!

I'm testing a new approach for gbak when used through services manager:
directly using VIO internal layer.

Preliminary tests showed a ~64% reduction in backup time and a ~37%
reduction in restore time. The test was performed on a single table with
10 million records and no indexes.

What do you think about this approach?


Adriano

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 22.08.2026 20:27:
> Preliminary tests showed a ~64% reduction in backup time and a ~37%
> reduction in restore time. The test was performed on a single table with
> 10 million records and no indexes.
>
> What do you think about this approach?

For me it looks like something between current BLR interface used by gbak and
VIO interface has an enormous overhead. Elimination of this overhead would
affect performance of every application, not only gbak.

--
WBR, SD.

[Vlad Khorsun]

22.08.2026 21:27, Adriano dos Santos Fernandes:

> Hi!
>
> I'm testing a new approach for gbak when used through services manager:
> directly using VIO internal layer.

Could you explain it ?

> Preliminary tests showed a ~64% reduction in backup time and a ~37%
> reduction in restore time. The test was performed on a single table with
> 10 million records and no indexes.

Sounds good. What was the base version for comparison ?

> What do you think about this approach?

Hard to say without details, sorry. But looks promising ;)

Regards,
Vlad

[Роман Симаков]

In spite of the promising results of the experiments I tend to support Dmitry's idea about overhead.

One of the approach is to avoid fetching records one by one and get as many records as possible at one call of engine. Something like "bulk select".

 

----------------

Кому: firebir...@googlegroups.com (firebir...@googlegroups.com);

Тема: [firebird-devel] New approach for gbak – significant performance improvements;

22.08.2026, 22:15, "'Dimitry Sibiryakov' via firebird-devel" <firebir...@googlegroups.com>:

--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/firebird-devel/2bad8656-7483-47b5-a3b9-9c9044cde026%40ibphoenix.com.

[Adriano dos Santos Fernandes]

On 8/22/26 19:23, Vlad Khorsun wrote:
> 22.08.2026 21:27, Adriano dos Santos Fernandes:
>> Hi!
>>
>> I'm testing a new approach for gbak when used through services manager:
>> directly using VIO internal layer.
>
>   Could you explain it ?

There is not too much secrets, just not-production ready code to test an
approach and see opinions.

src/burp call code that has two different implementations that is linked
in engine and in utility, so the new option is only available in
services manager.

Backup uses VIO_next_record. Restore uses VIO_store.

As restore create triggers and indices after records, VIO_store is the
simple thing that does the job of insert records in the database.

The is done in batch of 1000 records or 1MB per EngineContextHolder
entering. Without batch, backup performance was about ~50% reduction and
restore at ~20%.

>> Preliminary tests showed a ~64% reduction in backup time and a ~37%
>> reduction in restore time. The test was performed on a single table with
>> 10 million records and no indexes.
>
>   Sounds good. What was the base version for comparison ?

master with standard services manager.


Adriano

[Adriano dos Santos Fernandes]

On 8/23/26 02:19, Роман Симаков wrote:

> One of the approach is to avoid fetching records one by one and get as
> many records as possible at one call of engine. Something like "bulk
> select".
>  

Implementation has been changed with new options, but this was already
done long time ago. The BLR data requests was been generated with many
records sequentially instead of use one send/receive per record.


Adriano

[Роман Симаков]

Yes. Sorry, my fault. But it makes the overhead more unnatural. It seems really the root of the problem.

----------------

Кому: firebir...@googlegroups.com (firebir...@googlegroups.com);

Тема: [firebird-devel] New approach for gbak – significant performance improvements;

23.08.2026, 20:06, "Adriano dos Santos Fernandes" <adri...@gmail.com>:

--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/firebird-devel/d9adb59a-617a-43b1-b549-32017628c24c%40gmail.com.