Hi:

Does anyone have perfomance benchmark information about the memory
fragmentaion in CE.NET?
That means when application allocated a lots of random size blocks and
release randomly, over a certain period. We want to know how bad to
cause CE.NET performance? Some one claimed, "Dynamic allocation was
killer" in embedded realtime system? Is it true if the device had
large enough memory, like 64MB or event 128MB in CE.NET device? We
known that it is a serious factor in old-time when the device did not
have large memeory. But now we are talking over 64MB device. So how
the paging influence the performance in CE.NET?

Does anyone known what kind of algorithm used on CE.NET for memory
allocation, best-to-fit or some one else?

Thanks

Re: memory fragmentation by hel

hel
Tue Sep 23 12:01:28 CDT 2003

Use the source, luke. It's all there. Of course, if you listen
to the likes of sloh and pt, you can't comment on it here -- but
don't listen to them, not anymore than you'd take driving leasons
from the nutcase tailgating you at 70 mph on the off-ramp.

YDLU [23 Sep 2003 09:47:28 -0700]:
>Does anyone known what kind of algorithm used on CE.NET for memory
>allocation, best-to-fit or some one else?

But don't go here

http://www.theregister.co.uk/content/7/28724.html

because it shows how busy The Lawyers are. CE.NET, you mean 4.2?

--
40th Floor - Software @ http://40th.com/
GT40 encryption-database toolkit


Re: memory fragmentation by Paul

Paul
Tue Sep 23 12:20:59 CDT 2003

To be more specific, you can check the source, assuming you've installed it,
at \WINCE420\PRIVATE\WINCEOS\COREOS\CORE\LMEM.

There's also a 'debugging' tool that you can build into the OS, LMEMDEBUG,
which allows you to see what allocations are being done. You can find this
at \WINCE420\PUBLIC\COMMON\OAK\DRIVERS\LMEMDEBUG. The readme file in that
directory has some more information, also.

If you are writing something that must run real-time, it would be a good
idea to pre-allocate a block of memory large enough for all of your
allocations for the life of the real-time process and use a real-time
suballocation algorithm to handle allocations/deallocations yourself. Since
the OS itself has to worry about a lot of things that might happen, it has
to be very general-purpose and you can probably do better, since you know
more about the real situation.

Paul T.

<hel@40th.com> wrote in message
news:epuZVRfgDHA.2072@TK2MSFTNGP10.phx.gbl...
> Use the source, luke. It's all there. Of course, if you listen
> to the likes of sloh and pt, you can't comment on it here -- but
> don't listen to them, not anymore than you'd take driving leasons
> from the nutcase tailgating you at 70 mph on the off-ramp.
>
> YDLU [23 Sep 2003 09:47:28 -0700]:
> >Does anyone known what kind of algorithm used on CE.NET for memory
> >allocation, best-to-fit or some one else?
>
> But don't go here
>
> http://www.theregister.co.uk/content/7/28724.html
>
> because it shows how busy The Lawyers are. CE.NET, you mean 4.2?
>
> --
> 40th Floor - Software @ http://40th.com/
> GT40 encryption-database toolkit
>



Re: memory fragmentation by hel

hel
Tue Sep 23 12:38:36 CDT 2003

PT [Tue, 23 Sep 2003 10:20:59 -0700]:
>at \WINCE420\PRIVATE\WINCEOS\COREOS\CORE\LMEM.

It's really funny seeing you dance this way (yes, you are).

>> But don't go here (irony, of course)
>> http://www.theregister.co.uk/content/7/28724.html

The source is very cryptic, with way-too-few comments given the scope.
Hopefully he can get by without -- hold on pt --showing a line or two
of source. Yes, the Dance of Absurdity, flamenco style.

Do you really leave your pathnames upper-cased like that? I thought
I'd seen the last of that in 1994.

--
40th Floor - Software @ http://40th.com/
GT40 encryption-database toolkit


Re: memory fragmentation by Paul

Paul
Tue Sep 23 12:58:44 CDT 2003

I'm not dancing at all. There's nothing in the license agreement that I
have that talks about the structure in which the source code is stored. Nor
do I see a need to post portions of the source here. If someone asks a
question that can't be answered without publishing the source, I'll wait for
someone from MS to do it. I don't see how publishing a line or two of
source is going to decrypt it, if it's a mess, either.

Since it's important to you, I just copied the paths out of the Address edit
field in Explorer, for accuracy's sake. Apparently, the PB installer uses
all caps.

Paul T.

<hel@40th.com> wrote in message
news:OmpKFmfgDHA.1764@TK2MSFTNGP09.phx.gbl...
> PT [Tue, 23 Sep 2003 10:20:59 -0700]:
> >at \WINCE420\PRIVATE\WINCEOS\COREOS\CORE\LMEM.
>
> It's really funny seeing you dance this way (yes, you are).
>
> >> But don't go here (irony, of course)
> >> http://www.theregister.co.uk/content/7/28724.html
>
> The source is very cryptic, with way-too-few comments given the scope.
> Hopefully he can get by without -- hold on pt --showing a line or two
> of source. Yes, the Dance of Absurdity, flamenco style.
>
> Do you really leave your pathnames upper-cased like that? I thought
> I'd seen the last of that in 1994.
>
> --
> 40th Floor - Software @ http://40th.com/
> GT40 encryption-database toolkit
>



Re: memory fragmentation by Steve

Steve
Tue Sep 23 16:14:10 CDT 2003


Where can I get the weed you're smoking?



<hel@40th.com> wrote in message news:OmpKFmfgDHA.1764@TK2MSFTNGP09.phx.gbl...
> PT [Tue, 23 Sep 2003 10:20:59 -0700]:
> >at \WINCE420\PRIVATE\WINCEOS\COREOS\CORE\LMEM.
>
> It's really funny seeing you dance this way (yes, you are).
>
> >> But don't go here (irony, of course)
> >> http://www.theregister.co.uk/content/7/28724.html
>
> The source is very cryptic, with way-too-few comments given the scope.
> Hopefully he can get by without -- hold on pt --showing a line or two
> of source. Yes, the Dance of Absurdity, flamenco style.
>
> Do you really leave your pathnames upper-cased like that? I thought
> I'd seen the last of that in 1994.
>
> --
> 40th Floor - Software @ http://40th.com/
> GT40 encryption-database toolkit
>



Re: memory fragmentation by Bruce

Bruce
Wed Sep 24 08:53:44 CDT 2003

It is not weed, he is bitter because Susan correctly pointed out that he
violated his license agreement in a previous post. He does not understand
how this is true, because he confused license agreement with copyright.
These are two totally different legal matters.

The rest of us avoid this by posting file names containing the code so that
others can refer to the files, as Paul did. He considers this to be a
dance, and maybe it is, but it is the correct way to refer to licensed
source code in a public forum. With that said, I also don't see much of a
problem with posting a few lines of source code when absolutly necessary.

Really he should move on and get over it. It is a pity that he is wasting
his demonstrated talent with these types of posts.

--
Bruce Eitman (eMVP)
Senior Engineer
Accelent Systems Inc.
www.accelent.com



Re: memory fragmentation by hel

hel
Wed Sep 24 11:20:53 CDT 2003

I did exactly what I needed to to answer the question.

BE [Wed, 24 Sep 2003 09:53:44 -0400]:
>It is not weed, he is bitter because Susan correctly pointed out that he
>violated his license agreement in a previous post. He does not understand
>how this is true, because he confused license agreement with copyright.
>These are two totally different legal matters.

Spoken from someone that has no idea what he's saying.


Name one thing you do that is stupid, you know is stupid, but you
do it anyway because you have no backbone, can't think for yourself,
and prefer to cower behind the whim of others with a brown behind to
match your brown nose:

>The rest of us avoid this by posting file names containing the code so that

(haha)

>Really he should move on and get over it. It is a pity that he is wasting

I'm making at least a few people realize how absurd this finger-pointing
is (if you think citing some license on some web site I've never been
to, for something dated years after my source arrived, you don't seem
to think very well). If you want to see something with some meat, read
this and find out what really happened to Smartphone's first OEM.

http://www.theregister.co.uk/content/7/28724.html

I don't expect you to, but you're just not the type. It's a wonder
you can even stand up on your own with that back brace you need. Go
ahead, read it and compare and contrast this thread with that story.
Haha, yeah, right.

--
40th Floor - Software @ http://40th.com/
GT40 encryption-database toolkit


Re: memory fragmentation by Michael

Michael
Fri Sep 26 08:49:01 CDT 2003

There is no swap file in CE, so the only paging that happens is of read-only
segments such as code segments. No affect on heap allocations. The
commited part of your heap remains in memory while your process is running.

Fragmentation happens in any heap manager. CE does coalesce free blocks,
though.

As Paul mentioned, in a real realtime system (whatever that is), you have no
business using a heap manager. Use static buffers (or get all your
allocations out of the way at init time). The heap access is serialized -
plus whatever else overhead is in there. Use your own scheme for "dynamic"
allocations - one that doesn't use serialization.

--

Michael Salamone, eMVP
Entrek Software, Inc.
www.entrek.com


"YDLU" <yudiann.lu@sts.siemens.com> wrote in message
news:e37a1bda.0309230847.52ecec50@posting.google.com...
> Hi:
>
> Does anyone have perfomance benchmark information about the memory
> fragmentaion in CE.NET?
> That means when application allocated a lots of random size blocks and
> release randomly, over a certain period. We want to know how bad to
> cause CE.NET performance? Some one claimed, "Dynamic allocation was
> killer" in embedded realtime system? Is it true if the device had
> large enough memory, like 64MB or event 128MB in CE.NET device? We
> known that it is a serious factor in old-time when the device did not
> have large memeory. But now we are talking over 64MB device. So how
> the paging influence the performance in CE.NET?
>
> Does anyone known what kind of algorithm used on CE.NET for memory
> allocation, best-to-fit or some one else?
>
> Thanks