Re: [ros-kernel] Re: ROS gui

[Robert K. <ro...@ko...>]

Don't go into peanuts and don't count peas.
If you wanna get efficient programs, then use Registry as you want and 
use variables as you
want. As long as you don't use MFC (or th. like that) you'll save the 
most memory and CPU-time.

Royce Mitchell III schrieb:

>I considered this possibility, but I don't see how they would take up more
>room than the code. If you don't cache the data, then you have to at least
>put it on the stack or in a register. In order to get it there, you probably
>have to place a function call. There's a 5-byte instruction already. On top
>of that, we probably have to pass parameters to that function call. Let's
>say a pointer to the parameter name, or an identifier at least. We're up to
>9 bytes now. So, at a minimum, if we don't cache settings, we need at least
>9 bytes for every point of code where we wish to pull them in. OTOH, a mov
>eax, [var] is 5 bytes I think, 6 at most.
>
>If I'm mistaken, please show me the error of my ways :)
>
>It seems to me, if each setting is only accessed once, we save 4 bytes per
>variable for each one we cache. If a particular setting is accessed more
>often, then the savings only increase.
>
>I do realize there are more storage considerations, but I think they are
>moot, especially as a setting's usage increases.
>
>For example, let's say each setting is accessed via a 16-bit identifier ( to
>save space ). Let's also say there's a single function for loading
>parameters, and it only needs this 16-bit identifier to return the requested
>setting via EAX: There is only the size of the function for static storage
>requirements for all settings, and no static storage requirements for
>individual settings. Accessing each settings results in a 8-byte pair of op
>codes:
>    MOV AX, id ( 3 bytes )
>    CALL func ( 5 bytes )
>If we have 100 settings each accessed 100 times, this results in 80kb worth
>of code for utilizing the settings.
>
>OTOH, let's say we cache all settings. The same single function for loading
>parameters exists, so the storage space for this function is not necessary
>for this comparison. However, a new function exists which must be called on
>application startup which will cache all the settings ( perhaps in a
>background thread ). This function must call the loading function once for
>each of the 100 settings. Each setting is loaded like this:
>    MOV AX, id ( 3 bytes )
>    CALL func ( 5 bytes )
>    MOV [var], EAX ( 5 bytes )
>That results in an appx 1300 byte function. Now, for each setting to be
>accessed, we must do this:
>    MOV EAX, [var] ( 5 bytes )
>So, if each setting is accessed a 100 times, that results in 50kb worth of
>code to access the settings. Also, the program's memory footprint is
>increased by sizeof(var) * 100 = 400 bytes.
>Our total impact on memory comes to this: 1300 + 50000 + 400 = 51700.
>
>So, my attempt to compare the two comes up with this:
>
>non-cacheing: 80k
>cacheing: 52k
>
>I'm obviously not addressing performance issues, but I can't possibly see
>how (even) frequent cpu cache-misses could be slower than accessing the
>registry constantly.
>
>Royce3
>
>----- Original Message -----
>From: "Casper Hornstrup" <ch...@us...>
>To: <rea...@li...>
>Sent: Saturday, July 20, 2002 10:05 AM
>Subject: Re: [ros-kernel] Re: ROS gui
>
>
>lør, 2002-07-20 kl. 16:18 skrev Royce Mitchell III:
>  
>
>>----- Original Message -----
>>    
>>
>>>Looking up registry keys and values is not an expensive task in terms of
>>>time consumption, but keeping *all* settings in memory is expensive in
>>>      
>>>
>>terms
>>    
>>
>>>of memory consumption. This also obsoletes the concept of monitoring
>>>      
>>>
>>changes
>>    
>>
>>>to the registry, at least in most cases.
>>>      
>>>
>>Also, I forget to mention that most settings will take up less space than
>>the code to call the registry and reload it.
>>    
>>
>
>Maybe they do in your average free text editor application, but not in
>your average full blown comercial application with several thousands of
>settings.
>
>Casper
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>reactos-kernel mailing list
>rea...@li...
>https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>reactos-kernel mailing list
>rea...@li...
>https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>  
>