What pc hardware/software to speed up Microsoft Access? (4 Viewers)

A poor design will benefit from improved hardware performance just as much as a good design
A poor design may benefit, but likely not enough to make a difference. A form that is taking 30 seconds to open that now opens 20 seconds after adding $2000 in hardware on one computer is a failure. Spending $2000 in refactoring letting the form open in 3 seconds is a win for all your users.
 
The question isn't about which algorithm is better than another; it's clear that optimized code is faster than code that's just written the first time
But that's not the question
The question is "...which hardware/software guarantees better performance for an Access procedure..."
Where with "../software.." i means the operating system
 
Last edited:
The question isn't about which algorithm is better than another; it's clear that optimized code is faster than code that's just written the first time
But that's not the question
The question is "...which hardware/software guarantees better performance for an Access procedure..."
That is a meaningless question without knowing the procedure. My 1st example of a CPU centric process that could benefit from a CPU upgrade. Most Access procedures are data centric that may benefit from an IO upgrade, but what IO? Is the BE on a server or is it local? Does you process require scanning the tables or do you have a good data structure and indexing?
 
Perhaps you should also clarify what you mean by access procedure - a specific sub or function? Doing what? Is access split? If so where and what is the back end?
 
1 second from better cpu
1 second from better disk
1 second from better s.o.
are 3 second !!!
Well, as noted, you can get more then 1 second for some disk intensive tasks.
So, the better disk can help even more - that 15 seconds vs 14? Probably not going to be noticed.

But only focused on Microsoft Access, which hardware+software combination?

No real changes to my previous advice here. Anything more would be beyond my pay grade and knowledge.....

R
Albert
 
Some years ago we had PDP-11/70 that we used for, among other things, software development using cross-assemblers - like, writing a Motorola 6800-series code using a PDP-11 utility. As part of the process, because we had a Big-Endian/Little-Endian problem, we had to go into the binary download file and do byte-swap operations on the RIM-loader file that we used to burn ROM chips. The byte-swapper was written in BASIC which on the PDP-11 was compiled to machine code.

Then, because we needed to upgrade the overworked 11/70, we bought a VAX/VMS machine on a VAX 11/780 - supposedly a faster machine with wider data bus width. The byte-swap program in compiled BASIC code for the 11/70 that ran for 19 minutes on the old, clunky, slow PDP-11/70 was migrated to VAX code, also compiled BASIC for native VAX instructions. It took over 22 minutes. Needless to say, the boss was not a happy camper because that "hunk of junk" wasn't living up to expectations.

The guy in charge of the cross-compiler projects called me in to take a peek. I did a purely software fix by rewriting the byte-swapper in BASIC with one VAX Assembly-language subroutine that actually did the swapping step, leaving the other parts of the program still in BASIC compiled code to read the unswapped data or write the swapped data as an appropriate file type. The old pure-BASIC program that took (by system high-precision timer) 22 minutes 15 seconds now took 17 seconds on the new code.

We had a database compiler that worked on building proprietary databases with a hierarchical structure, tailored for the end product which was an industrial management system. On the VAX, the people who wrote the compiler bemoaned the fact that one compilation often took 70 hours or more, and one of our neighbors had some high-inductance motors that, when they started, caused a brown-out - thus killing the compile. So I analyzed the code, found a bottleneck, and fixed it. By removing one line of code (a particular subroutine call), I got the compiler to run in just a few seconds over one hour. The project leader was almost in tears she was so happy. If we had bought the biggest, fasted VAX available at the time, we would have had about a 50% speed increase on the instructions but the I/O was still going to depend on HDD latency and the nature of this beast was a paging problem. We couldn't afford to throw memory at it because the virtual size of the program never stopped growing. By removing one unneeded subroutine call, I obtained a 78-fold speed improvement. Not 78%... 78.6 TIMES faster, or about 98.8% speed increase, purely based on software.

The moral of this story? Don't put all of your improvement eggs in one basket. You WILL find a bottleneck somewhere after every hardware upgrade. It is inevitable.
 
The question is "...which hardware/software guarantees better performance for an Access procedure..."
Where with "../software.." i means the operating system
The best OS you can get is, again, I'm repeating myself because you don't seem to be reading all your replies, Windows 11, despite its flaws. MS Access is a Windows-only program and the only up-to-date and maintained Windows OS is Windows 11 right now. You want to use an actively maintained OS because if you don't, there are multiple risks involved in your operation. Some of these risks are: data theft, unwanted remote access, out-of-date components, etc.

There is a small chance that other versions of Windows run MS Access faster, given that Windows 11 is, right now, very bloated. But you risk too much. Now, nobody stops you from being careless and using severely outdated versions of software, like a severely outdated Windows 7 installation, for example. Or using a severely outdated version of MS Access, like Access 2003 or 2010, and I'm sure some forum members use 90s versions of Access for whatever reason, but that does not mean you should too. You should use whatever is being maintained. That includes the OS and the MS Access installation.

It has been recently established that MS Access 2016 can run on top of Linux, by using some non-vm tools, but I doubt it is stable, I might be wrong, but if it's stable, there is a high chance that it runs more smoothly there than on any version of Windows. But that's just speculation.

As for the hardware, again, I'm repeating myself, just find the best that you can with your budget and work on top of that.

Edit: MS Access can only be so fast at some point, it's meaningless trying to engineer where if you're not ready to spend some good bucks testing that, not even MS themselves know or want to test it. If you want vanguard state-of-the-art speed, go low and build your own database system or use something that works very close to the circuits of the board, bypassing multiple layers of user authorization, working in ring 0, choosing what each electron is doing. I mean, nobody stops you from going full TempleOS.
 
Last edited:
The moral of this story? Don't put all of your improvement eggs in one basket. You WILL find a bottleneck somewhere after every hardware upgrade. It is inevitable.

I can't agree more. Really, with the modern hardware we have?
It near all comes down to design, and the gains to be had for today's standard and decent hardware?
Not going to help. A mid range, or even bottom feeder computer today gives you what a state of the art $10,000 computer was 10 years ago.

There's just not really much of any tangible gains to be had here by throwing, or spending more money on hardware.

As I stated, and shared here?
In a typical developer day, the most benefits I had were in regards to disk drive speed improvements.
However, that means my next computer is unlikely to even help in this area, since some of those recent "big" gains in disk drive speed?
They have occurred, and of course have filtered their way down to even budget friendly computers now.

As most comments here show?
We realized the incredible performance gains, and we thus really don't gain much of anything by attempting to buy extra hardware to squeeze out a wee tiny bit more performance - such grains are not going to be noticed, or even of value to a typical developer.

Now, there have been times when the current computer I had was not enough. I think it was about 4 years ago, and when I upgraded from Visual Studio 2019 to 2022 on my laptop? it was just too much, and too slow to load !!! - time for a upgrade!!!



R
Albert
 

Users who are viewing this thread

Back
Top Bottom