Re: [ros-kernel] Re: ROS gui

[Jarmo M. <ja...@mu...>]

Hmm, others seem to have different way of programming than I have.
Lets say that I have few settings. I would write a class which has
interfaces for getting and setting values. Method is invisible to
the caller. It might use INI files or registry. It might read
settings from ini/reg every time it is called or it might cache
it.

In application class I'd have
private:
    Settings settings;

In code I'd have
    LANGID langID = settings.GetCurrentLanguageID();

So, from the caller's point of view there is no difference is it
cached or not. If it is cached, it might work a bit faster, if
used very frequently. If it is not cached, it would be a bit
slower, but it depends on what you're reading/writing and where
from/to.

Now to the code:

Non-cached version:

LANGID Settings::GetCurrentLanguageID()
{
    DWORD value;
    if ( QueryValue( TEXT("LanguageID"), value ) )
        return LANGID(value);

    return GetDefaultLanguageID();
}

Cached version:

class Settings
{
    ...
    private:
        LANGID currentLanguageID;
};

Settings::Settings()
{
    DWORD value;
    if ( QueryValue( TEXT("LanguageID"), value ) )
        currentLanguageID = LANGID(value);
    else
        currentLanguageID = GetDefaultLanguageID();
}

// this is so short that it is sensible to write a inline function
in .h
inline LANGID Settings::GetCurrentLanguageID() const
{
    return currentLanguageID;
}

Cached version with delayed query:

class Settings
{
    ...
    private:
        LANGID currentLanguageID;
};

Settings::Settings()
:    currentLanguageID( 0 )
{
}

LANGID Settings::GetCurrentLanguageID()
{
    if ( currentLanguageID == 0 )
    {
        DWORD value;
        if ( QueryValue( TEXT("LanguageID"), value ) )
            currentLanguageID = LANGID(value);
        else
            currentLanguageID = GetDefaultLanguageID();
    }

    return currentLanguageID;
}

Of course QueryValue is a function which queries DWORD value from
registry of from INI file. RegistryKey is opened in the first call
and the function itself knows where to read from.

Which one is fastest? Which one takes less memory? I actually
don't care, because it is dependent on frequent of usage. You just
cache some, if you feel that it's necessary.

JMu

----- Original Message -----
From: "Royce Mitchell III" <ro...@ev...>
To: <rea...@li...>
Sent: Monday, July 22, 2002 10:27 PM
Subject: Re: [ros-kernel] Re: ROS gui


> 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
>