Just venting - sometimes I hate Access.

[Killer42]

Argh!

Just got back to an old VB6 (at home) project I put on the back burner months ago. Among other things, it does a bit of image comparison, which appeared to be taking a ridiculously long time - like at least 5-10 seconds per image. I figured I just had some inefficient code there, it shouldn't take that long.

Well, I finally had a chance to dust off the source code and started logging some debugging messages at various points. It turns out that performing an update on single record in a pretty simple Access table, which contains around 3,000 records, is taking 8 seconds!

Ah well... I'll keep you guys posted on how it goes. Will probably come up with some questions along the way, but for now I don't remember enough about how it works to frame any reasonable questions.

[puppydogbuddy]

Argh!

Just got back to an old VB6 (at home) project I put on the back burner months ago. Among other things, it does a bit of image comparison, which appeared to be taking a ridiculously long time - like at least 5-10 seconds per image. I figured I just had some inefficient code there, it shouldn't take that long.

Well, I finally had a chance to dust off the source code and started logging some debugging messages at various points. It turns out that performing an update on single record in a pretty simple Access table, which contains around 3,000 records, is taking 8 seconds!

Ah well... I'll keep you guys posted on how it goes. Will probably come up with some questions along the way, but for now I don't remember enough about how it works to frame any reasonable questions.

Killer,

If you are working with images in ms access these links are a must!

http://www.jamiessoftware.tk/article...ingimages.html

http://www.ammara.com/start/index-aw...ture&net=0&st=

[NeoPa]

I don't really know why an update would take that long Killer, but I do know that Access tries to optimise things when it can and when it has enough information. Is your update being driven by software outside of the application (SQL running from VB for instance)?

[Killer42]

If you are working with images in ms access these links are a must! ...

Thanks for that. I'll file them away for future reference.

However, while the application is dealing with images, it doesn't store them.

[Killer42]

I don't really know why an update would take that long Killer, but I do know that Access tries to optimise things when it can and when it has enough information. Is your update being driven by software outside of the application (SQL running from VB for instance)?

I guess I'll have to pop over to Bill Gates' place and apologise for bad-mouthing his database software.

As it turns out, there was one more call in there that I had missed. As you might guess, it was this call (to an assembler routine that I wrote a few years back) to extract some information from the image which was taking the time, not the update.

I'll look into tweaking the routine if I can remember enough assembler, or maybe convert it back to VB. It was converted to assembler for speed, and in fact I think runs slower. Presumably because my asm sucks.

[NeoPa]

...
It was converted to assembler for speed, and in fact I think runs slower. Presumably because my asm sucks.

It's entirely possible.
Most compilers nowadays do contain a bunch of optimisations. Things that could speed up compiled code (among others of course) is string handling (80286+ processors provide some special instructions) and file-access buffering. The latter should be provided by the OS anyway but may be done more cleverly within compiled code.

[Killer42]

...string handling ... file-access buffering ...

The part that's taking too long just loops through the dots of an image, extracting colour information and so on. It does do quite a lot of processing, but I'm surprised it takes so long. Will have a fiddle when I can find time, and let you know how it goes. (May not be until the weekend.)

The funny things about this is, I think the assembler code slowed down considerably due to one of the Windows upgrades - I forget which one. I think it was basically when we went from cooperative to pre-emptive multitasking (I may have mentioned, this is an old program).

[FishVal]

Ah, you hurt me to the heart. In DOS times I used to be a rabid fan of asm. :)

Don't you want to post your asm routine if it is not too long?
And where did you place it? DLL?

Regards,
Fish

[Killer42]

Ah, you hurt me to the heart. In DOS times I used to be a rabid fan of asm. :)

I on;y ever dabbled a bit, but quite enjoyed it. You certainly can't beat it for processing speed. Or at least I would have said that, a few Windows versions ago.

Don't you want to post your asm routine if it is not too long?
And where did you place it? DLL?

Yes, it's a DLL. I'll see whether I can track down the source. Hm... not sure I want to give away too much of my application's workings, though (besides which, my assembler code is embarrassing).