> And, I've just learned that the new
> Delphi 64-bit compiler(hopefully released later this year) will only
> use fastcall for DLL interfaces(even Microsoft has that same
> restriction for 64-bit).
Where can i read about it ? Because i doubt fastcall is *only* supported
calling convention in
08.04.2011 3:57, Adriano dos Santos Fernandes wrote:
> For example, inserting in my table with one field could use a batching
> factor of 255 (maximum number of contexts) and is faster than with B =
> 1. For T10 with B = 5 it's faster, but for some (difficult to measure)
> larger B, it become slowe
08.04.2011 5:57, Adriano dos Santos Fernandes wrote:
> I do have some raw ideas to make batching on the message and request
> API, changing fetch to not return 100/101 but count of messages, and
> make possible to use input messages where is truly many messages
> concatenated.
Recently I was thin
On 07-04-2011 18:34, Vlad Khorsun wrote:
>> There is a simple change which makes it much faster, tested with Linux
>> 2.5 embedded restore:
>
> Well done ;)
>
> ...
>> My change creates this BLR:
>> blr_loop
>> blr_receive
>> blr_store
>> ...
>>
>> Calls isc_start_and_send first time then N-
> There is a simple change which makes it much faster, tested with Linux
> 2.5 embedded restore:
Well done ;)
...
> My change creates this BLR:
> blr_loop
> blr_receive
> blr_store
> ...
>
> Calls isc_start_and_send first time then N-1 isc_send.
Very good example of very old feature al
-=| Adriano dos Santos Fernandes, Thu, Apr 07, 2011 at 12:07:37PM -0300 |=-
> PS: There is other restore improvement capable of take down time
> from around 8.5s to 0.5s over TCP, but it still requires some
> analisys.
Now *that* would be a killer gbak improvement! Can we have it for
backup too
On 04/07/11 19:07, Adriano dos Santos Fernandes wrote:
> I suppose this works in all GBAK versions.
Great - I also see no reasons for this not to work for all FB versions.
--
Xperia(TM) PLAY
It's a major breakthrough. An
All,
It's expected that GBAK restores a database in the faster possible way.
It creates BLR, uses low level API and is built by people that know the
internals. :-)
But it does wrong!
There is a simple change which makes it much faster, tested with Linux
2.5 embedded restore:
Two databases, with
On 04/07/11 17:23, Daniel Rail wrote:
> Hi,
>
> At April-07-11, 9:44 AM, Dmitry Yemanov wrote:
>
>> I believe some form of queryInterface/upgradeInterface is required in
>> the API. But I don't think we should mimic IUnknown precisely without
>> really strong reasons. First of all, we don't need
On 04/07/11 16:59, Dmitry Yemanov wrote:
> 07.04.2011 16:47, Alex Peshkoff wrote:
>
>> But with smart pointers we must do the following:
>>
>> Smart at = ...
>> att->release();// refCounter == 1
>> att->blaBlaBla();
>>
>> We want to detach - and here problems come. We can't simply call:
>
Hi,
At April-07-11, 9:44 AM, Dmitry Yemanov wrote:
> I believe some form of queryInterface/upgradeInterface is required in
> the API. But I don't think we should mimic IUnknown precisely without
> really strong reasons. First of all, we don't need GUIDs as interface
> version identifiers, as ou
07.04.2011 16:47, Alex Peshkoff wrote:
> But with smart pointers we must do the following:
>
> Smart at = ...
> att->release();// refCounter == 1
> att->blaBlaBla();
>
> We want to detach - and here problems come. We can't simply call:
>
> att->detach();
>
> because ~Smart() will try to r
07.04.2011 16:09, Vlad Khorsun wrote:
> To protect us from the more then one call of detach() for the same instance.
> Example :
>
> IAttachment *att = provider->attach(...);
> doSomething(att);
> att->detach();
>
> doSomething(IAttachment *att)
> {
>if (something very bad happens)// t
On 04/07/11 15:09, Vlad Khorsun wrote:
We can fix engine (make PIO_create to create files in FW=ON mode, or add
new parameter to it)
>> I think we must take isc_dpb_gbak_attach into an account. When it is
>> set, let's keep old behavior.
> gbak is OK. It set isc_dpb_force_write at
On 04/07/11 14:55, Dmitry Yemanov wrote:
> 30.03.2011 21:45, Vlad Khorsun wrote:
>
>>> What would do a detach/commit/etc in an object when refcount> 1?
>> Call corresponding method of real object. And not touch refcount.
>>
>>> What would do a detach/commit/etc in an object when refcount = 1
All,
Speaking honestly, I've got lost in ping ponging between different
aspects of the topic. So feel free to correct me if I'll be going a
completely wrong way. And please forgive me for writing the obvious
things, as I tried to compose a complete picture for myself.
The basic requirement we
> 30.03.2011 21:45, Vlad Khorsun wrote:
>
>>> What would do a detach/commit/etc in an object when refcount> 1?
>>
>> Call corresponding method of real object. And not touch refcount.
>>
>>> What would do a detach/commit/etc in an object when refcount = 1?
>>
>> Same as above.
>
> Sorry
>>> We can fix engine (make PIO_create to create files in FW=ON mode, or add
>>> new parameter to it)
>
> I think we must take isc_dpb_gbak_attach into an account. When it is
> set, let's keep old behavior.
gbak is OK. It set isc_dpb_force_write at least since FB 1.5.
> And to minimize per
>> So, i think, this is the bug.
>
> Agreed.
>
>> We can fix engine (make PIO_create to create files in FW=ON mode, or add new
>> parameter to it) but
>> we can't fix old applications which creates database and expect fast work in
>> this first attachment.
>
> As for me, a possibility to have
30.03.2011 21:45, Vlad Khorsun wrote:
>> What would do a detach/commit/etc in an object when refcount> 1?
>
> Call corresponding method of real object. And not touch refcount.
>
>> What would do a detach/commit/etc in an object when refcount = 1?
>
> Same as above.
Sorry for ignorance,
On 04/07/11 14:39, Dmitry Yemanov wrote:
> 07.04.2011 14:15, Vlad Khorsun wrote:
>
>> So, i think, this is the bug.
> Agreed.
>
+1
>> We can fix engine (make PIO_create to create files in FW=ON mode, or add new
>> parameter to it)
I think we must take isc_dpb_gbak_attach into an account. When i
07.04.2011 14:15, Vlad Khorsun wrote:
> So, i think, this is the bug.
Agreed.
> We can fix engine (make PIO_create to create files in FW=ON mode, or add new
> parameter to it) but
> we can't fix old applications which creates database and expect fast work in
> this first attachment.
As for me
> On 04/07/11 11:00, Vlad Khorsun wrote:
>> Right after CREATE DATABASE and until disconnect database works with
>> actual FW=OFF,
>> despite of settings on header page. We specially didn't changed this to make
>> restore fast and
>> simple (no need to disconnect and no chance to lose exclus
On 04/07/11 11:00, Vlad Khorsun wrote:
> Right after CREATE DATABASE and until disconnect database works with
> actual FW=OFF,
> despite of settings on header page. We specially didn't changed this to make
> restore fast and
> simple (no need to disconnect and no chance to lose exclusive at
Vlad Khorsun wrote:
> Right after CREATE DATABASE and until disconnect database
> works with actual FW=OFF, despite of settings on header page.
> We specially didn't changed this to make restore fast and
> simple (no need to disconnect and no chance to lose exclusive
> attachment).
I am quite
> Right after CREATE DATABASE and until disconnect database works with
> actual FW=OFF,
> despite of settings on header page. We specially didn't changed this to make
> restore fast and
> simple (no need to disconnect and no chance to lose exclusive attachment).
AH, ok! This is an interesti
Right after CREATE DATABASE and until disconnect database works with actual
FW=OFF,
despite of settings on header page. We specially didn't changed this to make
restore fast and
simple (no need to disconnect and no chance to lose exclusive attachment).
Regards,
Vlad
---
27 matches
Mail list logo
