The in-memory representation of the DOM can get quite large, even for a limited amount of data. You may want to do some measurements on that before you get too deeply invested.
As for the data itself, a VB[S] string's total length is 8 + LenB(s). The 8 bytes are: 4 bytes for a pointer to the string storage, and 4 bytes to describe the length of the string. HTH, Tore. ----- Original Message ----- From: "Kevin Collins" <[EMAIL PROTECTED]> To: "ActiveServerPages" <[EMAIL PROTECTED]> Sent: Monday, October 28, 2002 9:32 AM Subject: RE: Measuring memory used in application variables > Hey Rob, > > I was just reading your N-Tier article this morning. Nice job! > > > Lenb() would be my best guesstimate also. Since it will store it in > > Unicode (dual byte code), it would make sense. > > Thanks, that's what I thought. > > > Im wondering...why do you need to measure memory? Scalability planning? > > Wouldn't such things as session useage, Ado useage, etc. make the > > biggest impact and such a significant different the APP variables would > > almost be negligable??? > > Well I'm considering an in-memory database solution as outlined here: > http://www.15seconds.com/issue/010409.htm > http://www.15seconds.com/issue/010410.htm > > The idea is to store a ton of data in the application object as a > free-threaded MSXML DOMDocument and execute search queries against it > using XPath. The author gives benchmark results that show it outperforming > standard ADO / SQL Server calls by a long shot. He shows some data on the > amount of memory used, but doesn't tell how he measured it. > > I know I can look at PerfMon or Task Manager before and after caching the > data, but using something like LenB() seemed like a more accurate way to > measure it. > > Kevin Collins > > --- > You are currently subscribed to activeserverpages as: [EMAIL PROTECTED] > To unsubscribe send a blank email to %%email.unsub%% > --- You are currently subscribed to activeserverpages as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED]
