[VCOM]First search takes too long time (was: Missing basic features ? ROADMAP)

[Joakim Schramm]

Hi,
 
> -----Original Message-----
> From: valentina-bounces at lists.macserve.net 
> [mailto:valentina-bounces at lists.macserve.net] On Behalf Of 
> Ruslan Zasukhin
> Sent: 21 March 2007 20:26
> To: valentina at lists.macserve.net
> Subject: Re: [DISCUSS] Missing basic features ? ROADMAP
> 
> On 21/3/07 8:06 PM, "Joakim Schramm" <joakim at astrocalc.com> wrote:
> 
> > Hi,
> > 
> > I tried this; Open the db in Vstudio and reindex, close. Create new 
> > setup with reindexed db. Intall fresh with db. First search, same 
> > problem, lot of disc activity (probably indexing) before result is 
> > returned. Furter searches instantly also after restart of 
> app, so it 
> > seem this is only on very first search of db. I don't 
> understand "why" 
> > it need to index if I already have done so?
> 
> I have to think...
> 
> Another variant can be -- you do some NOT-INDEXED search by 
> some field.
> 
No search in NOT-INDEXED field.

> It is know windows issue, that if you try touch some N MB 
> first time, Then it takes longer time. Second time virtual 
> memory compensate.
> 
Not sure if I understand this BUT if it was in play if would have been like
this from start, but this has started to happen lately.

> 
> So, if you have some column which is not indexed, and you do 
> search on it, then first time the whole column can be read 
> from HDD, second time it is in RAM of Windows.
> 
No I don't think this is the case.

> Again, Warning.log can help find this issue.
> 
I have done some research... Using timer to look at how long different
things take to do.

I init Valentina with cache 50 * 1048576, I think that should be 50MB

This is code now I init db

With mAtlasDB
    .InitLocal kStorageDisk
    .DateFormat = EVDateFormat.kYMD
    .Open AtlasPath
    .SqlExecute ("SET PROPERTY WarningMode TO TRUE")
    InitAtlasDB = .IsOpen
    .Close
End With

It takes almost no time, and here warning.log is not created.

As you notice I close db here, thi is just to check that db is in place and
open ok or app wont start.

Then in part were search is done, I check if db is open or I open it and
also so warning.log call. This reopen of db takes also almost no time
(15ms), but on close warning.log contain this line only;

FOR SQL QUERY TIME = 0 :

I have identified the delay is in the actuall search call. First time I call
this, and pass it an empty BitSet it takes about 11000 ms, if I not pass
empty set but use default optional = empty, call take "only" about 9000ms,
but when I do same call a second time after other use of program it takes
about 220ms. If I close app and open again same search call seem to take
little longer but not much 250-300ms, and Next (same) call though only takes
125ms.  The variations above 9000/11000 and 220/250-300 may have do with I
am using Vmware Workstation for testing. More important though which is new
finding, it seem not only happen first time of use for db BUT first time of
use for each Windows session and if I reboot and start this over I now have
13000ms for first call. This test have been using fld.FindStartWith only. I
will now go on making more tests but liked to report this as it's a bit
timeconsuming.

Also, this is a feeling just, but think this might have to do with same
thing as bug #2238 as I think this started to happen about the same time I
got an Empty set returned which is not set to Empty (by Valentina) when a
search fail.

Regards,
Joakim


>
http://www.valentina-db.com/dokuwiki/doku.php?id=paradigma:public:en:documen
tation:vsql:reference:get_set_property
> 
> 
> --
> Best regards,
> 
> Ruslan Zasukhin
> VP Engineering and New Technology
> Paradigma Software, Inc
> 
> Valentina - Joining Worlds of Information http://www.paradigmasoft.com
> 
> [I feel the need: the need for speed]
> 
> 
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina
>