XML vs Resource DLL String Access - Timing Results 
Author Message
 XML vs Resource DLL String Access - Timing Results

XML vs Resource DLL String Access - Timing Results

Good news and bad news.

Raw retrieval from XML is half as quick as from a resource DLL.

20 XML strings retrieved in 2ms
20 DLL strings retrieved in 1ms

(loop x10)

200 XML strings retrieved in 10 ms
200 DLL strings retrieved in 5 ms

These times include loading the XML DOM and loading the Resource DLL.

Although the Windows DLL outperforms the XML DOM by 2:1, I'm willing to bet
on XML. It's bound to be optimized as we go forward and XML has a functional
advantages over the DLL. For one thing, they're easy to generate. An XML
resource file can be generated a lot more easily than its counterpart DLL.

The bad news (for some) is that the initial DOM load of the XML resource
file was extremely poor, adding roughly between 30 & 50ms to the timing.
This appears to be 'per process' and I'm not sure whether this is due to XML
subsystem access or to file access. While this will not unduly burden a
persistent Windows client, server side transactions will suffer from this
performance hit if each transaction is executed by a new object. Perhaps
pooling will alleviate this. Or perhaps the DOM can be stored as an object
in the Application object for IIS apps. (DLL initial load also showed a
performance hit, although much smaller, between 5 and 10 ms)

Between timing tests, the DOM was unloaded and reloaded. I did not see the
50 ms hit except on the *initial* load. (Although for non-poolable stateless
server objects, every transaction would involve an initial load.) I suspect
XML subsystem access rather than file access. The file should be cached in
memory even for a separate process. This is a read-only operation so the
in-memory cache copy should be marked as 'clean' and no disk access should
be necessary.

If anyone can suggest methods for speeding up XML DOM instantiation, I'll be
happy to give them a shot and report back.

Thanks,
--

Joseph Geretz

(replace nospam with FPSNow to reply by e-mail)



Wed, 05 May 2004 03:06:15 GMT  
 XML vs Resource DLL String Access - Timing Results
Joseph,

    From what you have stated, it seems that your objects are designed
incorrectly.

    Assuming that you are running some sort of serviced component in
MTS/COM+, you have the ability to pool those objects (through the
IObjectControl interface).  You state that non-poolable stateless server
objects would always require this intial load.  This is true.  The thing is,
why would you make your objects so they are non-poolable?  The only reason I
can think of is if you are generating your components using VB6 and can't
control the threading model of the component.

    Making another assumption, that you are pooling your objects, your
initial load should be done once in the constructor for your object, not
when the object is activated.  This is where the difference lies.  Because
your strings are read-only, you only need to perform the load once.  Then,
every time your object is activated, you will have access to the document,
and the hit will be one time.  From what you said, it would appear that you
are performing the load every time the object is activated.

    Hope this helps.

--
                              - Nicholas Paldino [MVP]


Quote:
> XML vs Resource DLL String Access - Timing Results

> Good news and bad news.

> Raw retrieval from XML is half as quick as from a resource DLL.

> 20 XML strings retrieved in 2ms
> 20 DLL strings retrieved in 1ms

> (loop x10)

> 200 XML strings retrieved in 10 ms
> 200 DLL strings retrieved in 5 ms

> These times include loading the XML DOM and loading the Resource DLL.

> Although the Windows DLL outperforms the XML DOM by 2:1, I'm willing to
bet
> on XML. It's bound to be optimized as we go forward and XML has a
functional
> advantages over the DLL. For one thing, they're easy to generate. An XML
> resource file can be generated a lot more easily than its counterpart DLL.

> The bad news (for some) is that the initial DOM load of the XML resource
> file was extremely poor, adding roughly between 30 & 50ms to the timing.
> This appears to be 'per process' and I'm not sure whether this is due to
XML
> subsystem access or to file access. While this will not unduly burden a
> persistent Windows client, server side transactions will suffer from this
> performance hit if each transaction is executed by a new object. Perhaps
> pooling will alleviate this. Or perhaps the DOM can be stored as an object
> in the Application object for IIS apps. (DLL initial load also showed a
> performance hit, although much smaller, between 5 and 10 ms)

> Between timing tests, the DOM was unloaded and reloaded. I did not see the
> 50 ms hit except on the *initial* load. (Although for non-poolable
stateless
> server objects, every transaction would involve an initial load.) I
suspect
> XML subsystem access rather than file access. The file should be cached in
> memory even for a separate process. This is a read-only operation so the
> in-memory cache copy should be marked as 'clean' and no disk access should
> be necessary.

> If anyone can suggest methods for speeding up XML DOM instantiation, I'll
be
> happy to give them a shot and report back.

> Thanks,
> --

> Joseph Geretz

> (replace nospam with FPSNow to reply by e-mail)



Wed, 05 May 2004 03:35:35 GMT  
 XML vs Resource DLL String Access - Timing Results
Hi Nick,

Thanks for your feedback.

Everything you say is correct. Except for one thing. I didn't say I was
designing non-poolable objects. What I stated was that this factor would be
a problem for non-poolable objects. Others may be working with non-pooled
objects though, so it is worthwhile to note that the behavior exhibited
would be exacerbated in that type of scenario.

There are a few valid reasons for creating non-poolable objects. One is, as
you say, for developers working with VB6. Another situation which would call
for a non-poolable object is for any object whose creation (and destruction)
consumes less resources than its management in the pool. My results would
caution anyone with such non-pooled objects to take care when introducing
XML DOM manipulation into such an object, since that might very well make
the object 'heavy' to the point where poolability is indicated. (Of course,
if the developer was using VB6, then they'd be out of luck as far as pooling
is concerned. They'd have to work something else out in order to
compensate.)

As far as performing the DOM load in the constructor - absolutely correct.
That's why this initial load wouldn't be much of a factor for pooled
objects.

Have you or anyone else, actually been using this technique for resources in
a production scenario? I'd be interested in feedback from the field on this.
I already have an idea for speeding up the XML Node access by restructuring
the XML. I'll give it a shot and report back after the weekend. (My intent
here is not so much to address the initial load. I'm aiming to optimize the
string access time for each string. Although, *if* this simplifies the DOM,
perhaps it will load faster as well. We'll see.)

Thanks,
--

Joseph Geretz

(replace nospam with FPSNow to reply by e-mail)



Quote:
> Joseph,

>     From what you have stated, it seems that your objects are designed
> incorrectly.

>     Assuming that you are running some sort of serviced component in
> MTS/COM+, you have the ability to pool those objects (through the
> IObjectControl interface).  You state that non-poolable stateless server
> objects would always require this intial load.  This is true.  The thing
is,
> why would you make your objects so they are non-poolable?  The only reason
I
> can think of is if you are generating your components using VB6 and can't
> control the threading model of the component.

>     Making another assumption, that you are pooling your objects, your
> initial load should be done once in the constructor for your object, not
> when the object is activated.  This is where the difference lies.  Because
> your strings are read-only, you only need to perform the load once.  Then,
> every time your object is activated, you will have access to the document,
> and the hit will be one time.  From what you said, it would appear that
you
> are performing the load every time the object is activated.

>     Hope this helps.

> --
>                               - Nicholas Paldino [MVP]



> > XML vs Resource DLL String Access - Timing Results

> > Good news and bad news.

> > Raw retrieval from XML is half as quick as from a resource DLL.

> > 20 XML strings retrieved in 2ms
> > 20 DLL strings retrieved in 1ms

> > (loop x10)

> > 200 XML strings retrieved in 10 ms
> > 200 DLL strings retrieved in 5 ms

> > These times include loading the XML DOM and loading the Resource DLL.

> > Although the Windows DLL outperforms the XML DOM by 2:1, I'm willing to
> bet
> > on XML. It's bound to be optimized as we go forward and XML has a
> functional
> > advantages over the DLL. For one thing, they're easy to generate. An XML
> > resource file can be generated a lot more easily than its counterpart
DLL.

> > The bad news (for some) is that the initial DOM load of the XML resource
> > file was extremely poor, adding roughly between 30 & 50ms to the timing.
> > This appears to be 'per process' and I'm not sure whether this is due to
> XML
> > subsystem access or to file access. While this will not unduly burden a
> > persistent Windows client, server side transactions will suffer from
this
> > performance hit if each transaction is executed by a new object. Perhaps
> > pooling will alleviate this. Or perhaps the DOM can be stored as an
object
> > in the Application object for IIS apps. (DLL initial load also showed a
> > performance hit, although much smaller, between 5 and 10 ms)

> > Between timing tests, the DOM was unloaded and reloaded. I did not see
the
> > 50 ms hit except on the *initial* load. (Although for non-poolable
> stateless
> > server objects, every transaction would involve an initial load.) I
> suspect
> > XML subsystem access rather than file access. The file should be cached
in
> > memory even for a separate process. This is a read-only operation so the
> > in-memory cache copy should be marked as 'clean' and no disk access
should
> > be necessary.

> > If anyone can suggest methods for speeding up XML DOM instantiation,
I'll
> be
> > happy to give them a shot and report back.

> > Thanks,
> > --

> > Joseph Geretz

> > (replace nospam with FPSNow to reply by e-mail)



Wed, 05 May 2004 04:15:21 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Accessing resource file string table from within a DLL (using MFC)

2. Accessing resource file string table from within a DLL (using MFC)

3. How to cycle through the strings in the string table of a resource DLL

4. how to create string resource at run time

5. Accessing String Table Resources

6. Accessing resources (version and strings)

7. Cross checking C/C++ string constants with an XML file that has sthe same strings

8. Using EnumTypesFunc to get access to resource from loaded DLL

9. Q: Accessing resources in a dll

10. Accessing DLL resources with LoadImage

11. Accessing resources in EXE from DLL

12. Using EnumTypesFunc to get access to resource from loaded DLL

 

 
Powered by phpBB® Forum Software