slow down between different verions of mydac for builder 6.
slow down between different verions of mydac for builder 6.
About 6 months ago I down loaded the mydac for builder 6 trial, but ended up not using it.
I now need something like that, so I thought I'd evaluated the crlab offering against the microOLAP one.
One thing was quickly apparent - myDac (crlab:-) was substantially faster - running selects against either local or remote databases in two thirds the time of the microOLAP product. It also ran insert commands over twice as fast (on the same hardware, with the same database) as the microOLAP one!
So an easy decision!
However, when I down loaded the current 3.50.0.17 24.02.05 - just do a final test before I bought it - I re ran my timing tests (after rebuilding the applicatiom of course).
Select statements now run at half the speed they did (compared to version 3.10.0.5 08.07.04) (ie now slower than micoOLAP) and inserts are 20% slower than what they were (though still twice as fast as microOLAP).
Any idea why this would be happening?? Is there some new option that I need to turn on for the latest release? Or has there been a bit of code bloat, and things have just slowed down?
I now need something like that, so I thought I'd evaluated the crlab offering against the microOLAP one.
One thing was quickly apparent - myDac (crlab:-) was substantially faster - running selects against either local or remote databases in two thirds the time of the microOLAP product. It also ran insert commands over twice as fast (on the same hardware, with the same database) as the microOLAP one!
So an easy decision!
However, when I down loaded the current 3.50.0.17 24.02.05 - just do a final test before I bought it - I re ran my timing tests (after rebuilding the applicatiom of course).
Select statements now run at half the speed they did (compared to version 3.10.0.5 08.07.04) (ie now slower than micoOLAP) and inserts are 20% slower than what they were (though still twice as fast as microOLAP).
Any idea why this would be happening?? Is there some new option that I need to turn on for the latest release? Or has there been a bit of code bloat, and things have just slowed down?
Ok, will do that after I take out any compile dependencies. I'll also change it to also create the test data in a table, so that I don't have to email you a table with 4 million rows! At the moment this is created by a program anyway (I made it just for testing) I'll email it in within 24 hours..
It's a pretty consistently change across all the tests I've run, so may just be an unfortunate consequent of increased functionality....
It's a pretty consistently change across all the tests I've run, so may just be an unfortunate consequent of increased functionality....
-and a question off on a tangent - what is the 'upgrade policy'? I assume if someone buys v.3.50.0.17 today, they will get 3.50.0.18 sent to them when it is released? How far out does that extend, and what happens when you do major releases like 3.6, or 4.0? I can't find anywhere on your web site that discusses this.
> I'm impressed with the fast turn around - but could you tell me what the
> problem was?
We added support of CommandTimeout at TCP sockets level. As it turned out
it is not quite correct from the point of view of performance.
> And would it be possible to have a fixed version so I could
> do some testing for you?
Usually we don't send intermediate versions.
> problem was?
We added support of CommandTimeout at TCP sockets level. As it turned out
it is not quite correct from the point of view of performance.
> And would it be possible to have a fixed version so I could
> do some testing for you?
Usually we don't send intermediate versions.
OK, not a problem. If you send me an email when it is released I'll download it, confirm the fix, and then order the product.Ikar wrote:>
> And would it be possible to have a fixed version so I could
> do some testing for you?
Usually we don't send intermediate versions.
And my other question on upgrading between versions?
> -and a question of on a tangent - what is the 'upgrade policy'? I assume if
> someone buys v.3.50.0.17
> today, they will get 3.50.0.18 sent to them when it is released? How far out
> does that extend, and
> what happens when you do major releases like 3.6, or 4.0? I can't find
> anywhere on your web site
> that discusses this.
By our upgrade policy, only mayor upgrade is paid. All upgrades to further 3.xx versions will be free. Even if two years later you find an error in this version, we'll fix it and you'll get upgrade for free.
> someone buys v.3.50.0.17
> today, they will get 3.50.0.18 sent to them when it is released? How far out
> does that extend, and
> what happens when you do major releases like 3.6, or 4.0? I can't find
> anywhere on your web site
> that discusses this.
By our upgrade policy, only mayor upgrade is paid. All upgrades to further 3.xx versions will be free. Even if two years later you find an error in this version, we'll fix it and you'll get upgrade for free.
Ok, you just must not be too keen on me buying it... And I've already found a bug in it for you to I'll keep an eye on your web site for when you release one with the fix - after all, the bug doubled the time it took for the select statements I was using!Ikar wrote:>
We send notification email messages about new version releases only for registered users now. Please see announcements at our site.