Cashing in on Cache (1 Viewer)

isladogs

MVP / VIP
Local time
Today, 08:30
Joined
Jan 14, 2017
Messages
18,186
The implications of your post was that caching used to have a more significant effect than is the case nowadays.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:30
Joined
Feb 28, 2001
Messages
27,001
Found a reference, not the one I remembered, but it shows something similar.

https://www.researchgate.net/publication/2952862_Demand_Paging_in_Perspective

Caching and demand paging are different in how they occur but are highly similar in their effects. There is an old word you can look up that describes that point in my diagram where the second inflection occurs. It is the "top knee" of the s-curve, located by taking derivatives of the curves until you find that bottoming-out blip. That point is called the parachor. Sadly, a physical chemistry measurement uses the same name and is now more common. You would only find references on this subject if you looked up "parachor + virtual memory"
 

NauticalGent

Ignore List Poster Boy
Local time
Today, 04:30
Joined
Apr 27, 2015
Messages
6,286
So...I took a swing at this today in an attempt to improve my apps performance in the Middle East. I won't be able to get any feedback until Monday, but wanted to run this by you all for S&G...

On my form's OnOpen Event it did something like this:
Code:
...Dim statements

Set rs = db.OpenRecordset("Select..., dbOpenDynaset, dbSeeChanges)
With rs
   .CacheSize = .Recordcount
   .FillCache
End With

Set Me.Recordset = rs

Exit routines

It seems to work fine, but then with the Server being less then 100 feet away, it was plenty fast already.

Thoughts?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:30
Joined
Feb 28, 2001
Messages
27,001
The implications of your post was that caching used to have a more significant effect than is the case nowadays.

Memory is cheaper now so it is easier to just push the envelope to the point that your image fits into memory completely. In my post above, I pointed out that the best virtual performance comes if you have all of the process in memory. If you can afford that much memory, you never have to wait for a page-swap. And at that point, virtual demand paging has a lot less to do. (Still never quite zero because of all of the frimpin' Windows Services that clutter up memory and then promptly go idle.)

Consider that in the days of MS-DOS, a machine with 640KB was the biggest memory you could have due to memory bus size and segmentation limits. (They called it "partitioning.") As recently as Windows 3.1, physical memory was still limited because Windows "rode" DOS, so the limits still applied. Bigger memory was possible but you needed extra software acting as a memory-control-register driver. Using that kind of memory driver, the biggest memory I ever saw was 2 GB as an upper limit. It actually took the advent of Windows NT to break that barrier "for real." Even then, you had the limit of 4 GB of physical memory (of which a fraction was never usable). But now it is a few hundred bucks to get 16 GB of RAM. If you are using 32-bit Office, the implications are that you eat about 3-5 GB for Windows and ALL of its junk, then with 11 GB of RAM you can have a 2 GB Access DB, a very large spreadsheet, a huge Word document, and a PowerPoint presentation ALL active at once, with Outlook in the background, and NONE Of them would be swapped out or paged out.

Another factor is that caching STILL has a TREMENDOUS effect - but it is not obvious to you because it is not out in front any more. That's OK, I can tell you how to find out about it. Modern machines have hardware caches, usually called the L1, L2, and L3 caches - that hold frequently referenced items from memory in a part of the memory circuitry that is electronically closer to the CPU than the memory bus interface. You can look these up if you wish, but basically they are INVISIBLE caches that really shine when you have relatively small program loops. If you are using Win10, call up Task Manager and call up the performance page, click on the CPU performance option (left margin), then look to the lower right. It will tell you what size you have for the physical memory caches. (Or at least it does so on my system.) You can also click on the Memory performance option, to see some things that relate to how much more you can fit into the sardine can. Look for the COMMITED number, which is a fraction. That number is, in essence "what you use/what you COULD use" on your machine.

Then, if you REALLY get curious, from the bottom of that page you can call up Resource Monitor. Call that up and select the Memory tab. The nomenclature that they use has changed a bit over the years. They have a "Modified" component that represents the modified page list, and it is usually relatively small. Their "Standby" component is part of what I am calling the "Free Page List." You will also see "hardware reserved" memory which is related to non-swappable parts of memory that are tied to interrupt handling and the physical segmentation registers. There is also the "In Use" section, which is memory that is currently allocated to a specific process. You might actually see something called "Free" but in this context, I believe it is physical memory that has never been used or for which the contents were invalidated by process exit, and therefore do not hold anything in "Standby" status.

If you look up the topic "Windows Paging Dynamics" you would realize that the Free Page List and Modified Page List (taken together) are ALSO a form of cache. If you paged out of memory to the swap file (virtual memory file), then you have to come out of the page file to be back in memory again. But if you were merely remapped to the Modified Page List preparatory to being outswapped, your memory segments can be reclaimed from the MPL. And if you were written out to the swap file BUT the memory pages hadn't been overwritten, Windows remembers what was last there and just remaps you to those pages rather than reading them in. (That's the magic of modern memory management hardware.)

All of those things I just mentioned are more modern forms of caching as applied by the Windows O/S or CPU hardware, usually transparently. Which is why it only "seems" that it is less effective.
 

Gasman

Enthusiastic Amateur
Local time
Today, 08:30
Joined
Sep 21, 2011
Messages
14,050
So...I took a swing at this today in an attempt to improve my apps performance in the Middle East. I won't be able to get any feedback until Monday, but wanted to run this by you all for S&G...

On my form's OnOpen Event it did something like this:
Code:
...Dim statements

Set rs = db.OpenRecordset("Select..., dbOpenDynaset, dbSeeChanges)
With rs
   .CacheSize = .Recordcount
   .FillCache
End With

Set Me.Recordset = rs

Exit routines

It seems to work fine, but then with the Server being less then 100 feet away, it was plenty fast already.

Thoughts?
I *thought* that recordcount was not determined until a MoveLast had been called when opening a recordset? :confused:

I've just tested with code below and I got 1?

Code:
Sub TestEOF()
Dim strSQL As String
Dim rs As Recordset

With CurrentDb.OpenRecordset("Select * from Transactions")
    If .BOF Then
        MsgBox "Empty File"
    Else
        '.MoveFirst
        MsgBox "Records exist record count is " & .RecordCount
        
'        Do Until .EOF
'            MsgBox !EmployeeName
'            .MoveNext
'        Loop
    End If
    .Close
End With

End Sub
 

NauticalGent

Ignore List Poster Boy
Local time
Today, 04:30
Joined
Apr 27, 2015
Messages
6,286
I *thought* that recordcount was not determined until a MoveLast had been called when opening a recordset? :confused:

I've just tested with code below and I got 1?

Code:
Sub TestEOF()
Dim strSQL As String
Dim rs As Recordset

With CurrentDb.OpenRecordset("Select * from Transactions")
    If .BOF Then
        MsgBox "Empty File"
    Else
        '.MoveFirst
        MsgBox "Records exist record count is " & .RecordCount
       
'        Do Until .EOF
'            MsgBox !EmployeeName
'            .MoveNext
'        Loop
    End If
    .Close
End With

End Sub
Right you are! And here I thought I was being so cute. Thanks Paul, I'll fix that first thing...anything else?
 

Gasman

Enthusiastic Amateur
Local time
Today, 08:30
Joined
Sep 21, 2011
Messages
14,050
Easily done. :)
That code was actually to test why people use If NOT .BOF and NOT .EOF when I believe .BOF or .EOF on their own will suffice if a file is empty.?
I just modfied the filename and added the record count to check.

What would be the consequences if the file had a huge number of records?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:30
Joined
Feb 28, 2001
Messages
27,001
Gasman said:
I believe .BOF or .EOF on their own will suffice if a file is empty.?

If <recordset>.BOF is always true after opening a recordset (because the db.OpenRecordset implies rs.MoveFirst) so an IF rs.BOF tells you nothing. However, an IF rs.EOF when a recordset is first opened SHOULD indicate an empty recordset. Having .EOF and .BOF true at the same time guarantees an empty recordset.
 

Gasman

Enthusiastic Amateur
Local time
Today, 08:30
Joined
Sep 21, 2011
Messages
14,050
The_Doc_Man,
I can only say what I find.?

The above code with an empty file displays "Empty File"
The above code with an non empty file display the record count of 1 ?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:30
Joined
Feb 28, 2001
Messages
27,001
OK, Gasman, I remembered it wrong. So before sticking my foot deeper, I looked it up. Here is a discussion on the topic.

 

Users who are viewing this thread

Top Bottom