|As long as the threading model of the thread matches that of the component, there shouldn't be any proxy/stub work going on, and the call into the component is just a virtual function call, which isn't much more costly than a non-virtual call.
If both parts (client and component) are written in C++, or if the client is VB6, try to ensure that your component exposes a vtable interface as well as the dispatch interface - a dual interface, as it's known. This is basically a custom interface derived from IDispatch, so that callers which can early bind do so, while late-binding callers aren't shut out.
If the threading model of the component doesn't match the threading model of the caller, COM will introduce a proxy and stub to marshal between the caller and the component within the thread. This is less costly than having the component as a local server process, but more costly than a plain call.
This might happen if your component is marked 'Free' but your client is either VB6, or calls
CoInitializeEx( NULL, COINIT_APARTMENTTHREADED ); to initialise COM from C++. If the component is marked 'Both', it will behave as if you'd specified 'Apartment' if the thread that created it runs in the Single-Threaded Apartment (conditions as above), or 'Free' if the creator runs in the Multi-Threaded Apartment.
I suspect, though, that your database accesses are what's killing you. Measure the actual performance of Access on that system configuration. It's going to be sluggish - indeed with only 24Mb of RAM, it's likely to be constantly swapping.
Generally it's a good idea to compile your app with the 'Minimize Size' compiler options - in VB, this is Project Properties > Compile tab > select Compile to Native Code and Optimize for Small Code.
In VC 6.0, I use the /Oxs option - full optimization, favor small code - and the /Og option - global optimizations. I also use /Gy (enable function-level linking) and specify /OPT:REF to the linker (Remove unreferenced functions). This last is the default, but it gets turned off if you generate debugging information for the release build, which I do. Specifying /OPT:WIN98 might improve your startup time on Windows 98.
Doing this can reduce your code size, which can reduce the number of page faults you take.
You could also try using a profiler to find out where the hotspots are. The Win32 SDK contains a tool called the Call Attributed Profiler, or CAP.