ppc windows mobile slow slow

[ed via DotNetMonster.com]

Hi

I am writing code for windows mobile 2003 second edition. everything works,
just really slow I am not sure what;s going on. If I don't have extra
financial resources to buy more momory, how can I fix it in code? Has anyone
wrote something in ppc windows mobile env and program was executing slow?

I have 2 threads not counting main application thread runnin with the main
thread. None of the tasks that I am doing seem cpu intensive. should I not
have been using threads?

Any help at all is greatly appreciated.

Ed

 

[Paul G. Tobey [eMVP]]

You've given us *no* useful information that would help us to help you.
What does your code do, for example? What have you tried to improve the
situation? It's unlikely that more RAM is going to help, even if your
device is upgradeable. Better design of your code might help...

I doubt that threading is the problem, unless you are doing lots of
synchronization between the threads.

Paul T.

 

[ed via DotNetMonster.com]

Thanks Paul, I was wondering if it could be the threading. So far I am still
trying to narrow down the main problem area in my code. For some reason the
DateTime.Ticks() and DateTime.MilliSeconds property always return 0 to me in
CF.

my code talks with built-in serial bluetooth and fetches commands for
processing and output. Surely, the BT reading of information might cause
some delay but I think only on the initial connect. I am still trying to get
the DateTime to work right so I can pinpoint the problem area. I tried
taking out controls in the gui and it seems to have improved a little. I
tried ignoring about 1/3 of the commands to be interpreted but it didn't seem
to help. if I tap menu items(i.e File, etc), it sometimes goes into a long
lag. Other times, when I tap the menu item again <- to make menu disappear
(or I could've tapped anywhere else on my form), the refresh will be laggy or
it won't finish. The refresh performance definately improve if I keep
tapping the form. Hope this is not too confusing... here is my attempt to
simplify this part.
tap File = sometimes lags for a long time.
tap File again or attempt to suppress the menu options = either doesn't
complete the refresh or it refreshes slow, refresh will complete if I tap in
the form again. this problem is true when I tap the buttons too, sometimes
I'll have to tap the screen for a long time before I can see the button
reaction.

Do you know why DateTime class laughed at me when I tried to get the Tick
count or the milliseconds count?
dim dt as new DateTime
x = dt.ticks() <- x becomes 0
x = dt.Milliseconds <- x also becomes 0

so many problems in 1 post... sorry about that Paul. Thank you very much
for your time and effort. If nothing else, can you help me get the DateTime
thing working? at least that way I can better pin point the tumor in my code.


I had designed most of my code in O(n) order or less(or as close to that as I
can). <- at least I thought.

You've given us *no* useful information that would help us to help you.
What does your code do, for example? What have you tried to improve the
situation? It's unlikely that more RAM is going to help, even if your
device is upgradeable. Better design of your code might help...

I doubt that threading is the problem, unless you are doing lots of
synchronization between the threads.

Paul T.

Hi

[quoted text clipped - 13 lines]

Ed

 

[Paul G. Tobey [eMVP]]

Just to be sure, you're running this code where? Any time you're thinking
about performance, forget about the emulator.

DateTime.Ticks should, I think return the tick count since Windows CE booted
(and it works on my 4.2-based devices), but DateTime.MilliSeconds being zero
is totally expected. Most of the real-time clocks on these processors don't
return date/time to that resolution. You might try DateTime.Now.Ticks,
rather than creating a new object yourself, since what you want is the
current time.

As far as timing events, look at OpenNETCF SDF. There's a stopwatch class
in there that you can use.

You should be sure that you aren't doing things that might take a long time
from the GUI thread (connecting to the the BT device is a good candidate for
a separate thread). That would affect the user interface responsiveness,
which seems to be your main complaint.

Paul T.

Thanks Paul, I was wondering if it could be the threading. So far I am
still
trying to narrow down the main problem area in my code. For some reason
the
DateTime.Ticks() and DateTime.MilliSeconds property always return 0 to me
in
CF.

my code talks with built-in serial bluetooth and fetches commands for
processing and output. Surely, the BT reading of information might cause
some delay but I think only on the initial connect. I am still trying to
get
the DateTime to work right so I can pinpoint the problem area. I tried
taking out controls in the gui and it seems to have improved a little. I
tried ignoring about 1/3 of the commands to be interpreted but it didn't
seem
to help. if I tap menu items(i.e File, etc), it sometimes goes into a
long
lag. Other times, when I tap the menu item again <- to make menu
disappear
(or I could've tapped anywhere else on my form), the refresh will be laggy
or
it won't finish. The refresh performance definately improve if I keep
tapping the form. Hope this is not too confusing... here is my attempt
to
simplify this part.
tap File = sometimes lags for a long time.
tap File again or attempt to suppress the menu options = either doesn't
complete the refresh or it refreshes slow, refresh will complete if I tap
in
the form again. this problem is true when I tap the buttons too,
sometimes
I'll have to tap the screen for a long time before I can see the button
reaction.

Do you know why DateTime class laughed at me when I tried to get the Tick
count or the milliseconds count?
dim dt as new DateTime
x = dt.ticks() <- x becomes 0
x = dt.Milliseconds <- x also becomes 0

so many problems in 1 post... sorry about that Paul. Thank you very much
for your time and effort. If nothing else, can you help me get the
DateTime
thing working? at least that way I can better pin point the tumor in my
code.


I had designed most of my code in O(n) order or less(or as close to that
as I
can). <- at least I thought.

You've given us *no* useful information that would help us to help you.
What does your code do, for example? What have you tried to improve the
situation? It's unlikely that more RAM is going to help, even if your
device is upgradeable. Better design of your code might help...

I doubt that threading is the problem, unless you are doing lots of
synchronization between the threads.

Paul T.

Hi

[quoted text clipped - 13 lines]

Ed

 

[ed via DotNetMonster.com]

hi Paul:

I am running this on PPC windows mobile 2003 second ed. From what I've read,
it seems that CE is much closer to the desktop windows than ppc is.

Thanks, I will now try to find out where the issue is.

Just to be sure, you're running this code where? Any time you're thinking
about performance, forget about the emulator.

DateTime.Ticks should, I think return the tick count since Windows CE booted
(and it works on my 4.2-based devices), but DateTime.MilliSeconds being zero
is totally expected. Most of the real-time clocks on these processors don't
return date/time to that resolution. You might try DateTime.Now.Ticks,
rather than creating a new object yourself, since what you want is the
current time.

As far as timing events, look at OpenNETCF SDF. There's a stopwatch class
in there that you can use.

You should be sure that you aren't doing things that might take a long time
from the GUI thread (connecting to the the BT device is a good candidate for
a separate thread). That would affect the user interface responsiveness,
which seems to be your main complaint.

Paul T.

Thanks Paul, I was wondering if it could be the threading. So far I am
still

[quoted text clipped - 62 lines]

 

[Paul G. Tobey [eMVP]]

Pocket PC is based on Windows CE... WM2003SE is based on CE.NET 4.2, just
as the device I'm testing is.

Paul T.

hi Paul:

I am running this on PPC windows mobile 2003 second ed. From what I've
read,
it seems that CE is much closer to the desktop windows than ppc is.

Thanks, I will now try to find out where the issue is.

Just to be sure, you're running this code where? Any time you're thinking
about performance, forget about the emulator.

DateTime.Ticks should, I think return the tick count since Windows CE
booted
(and it works on my 4.2-based devices), but DateTime.MilliSeconds being
zero
is totally expected. Most of the real-time clocks on these processors
don't
return date/time to that resolution. You might try DateTime.Now.Ticks,
rather than creating a new object yourself, since what you want is the
current time.

As far as timing events, look at OpenNETCF SDF. There's a stopwatch class
in there that you can use.

You should be sure that you aren't doing things that might take a long
time
from the GUI thread (connecting to the the BT device is a good candidate
for
a separate thread). That would affect the user interface responsiveness,
which seems to be your main complaint.

Paul T.

Thanks Paul, I was wondering if it could be the threading. So far I am
still

[quoted text clipped - 62 lines]

Ed

 

[ed via DotNetMonster.com]

Paul:

I know it's based on CE but I thought the .net CF for ppc is yet another
subset of .net CF? I have tested my code and traced through by code after I
added the tick count vars into the app, gui's me.refresh hangs. This is the
first time I have seen me.refresh in a form that would hang. I had
previously assumed that microsoft built-in functions would work all the time..
.. I have something along the lines of :

main:
info received,
new_time_stamp
diff = ne_ time_stamp - old_time_stamp
old_time_stamp = new_time_stamp
gui.display_timestamp(diff)

gui:
display_timestamp:
label_of_timestamp.text = diff.ToString()

OnPaint():
label1.text = get_display_info_string1 <-pre-calculated string of displaying
info
label2.text = get_display_info_string2 <- both precalculated
mybase.onpaint()

Pocket PC is based on Windows CE... WM2003SE is based on CE.NET 4.2, just
as the device I'm testing is.

Paul T.

hi Paul:

[quoted text clipped - 34 lines]

--
"What if this is as good as it gets?"


Message posted via DotNetMonster.com
http://www.dotnetmonster.com/Uwe/Forums.aspx/dotnet-compact-framework/200508/1

 

[Paul G. Tobey [eMVP]]

No, the same .NET CF 1.0SP3 that runs on your PPC2003SE is what's running on
our 4.2-based device with the latest CE components installed. It might have
some different behaviors based on the platform (where tabs on tabbed forms
are), but I think that the basic operations are identical.

The .NET CF is *very* sensitive to calling any GUI-related method from a
non-GUI thread. This has been covered here in the newsgroup over and over
again, along with how to use Invoke to get around it. My first guess is
that you're calling some GUI-thread-only method from another thread.

Paul T.

Paul:

I know it's based on CE but I thought the .net CF for ppc is yet another
subset of .net CF? I have tested my code and traced through by code after
I
added the tick count vars into the app, gui's me.refresh hangs. This is
the
first time I have seen me.refresh in a form that would hang. I had
previously assumed that microsoft built-in functions would work all the
time..
. I have something along the lines of :

main:
info received,
new_time_stamp
diff = ne_ time_stamp - old_time_stamp
old_time_stamp = new_time_stamp
gui.display_timestamp(diff)

gui:
display_timestamp:
label_of_timestamp.text = diff.ToString()

OnPaint():
label1.text = get_display_info_string1 <-pre-calculated string of
displaying
info
label2.text = get_display_info_string2 <- both precalculated
mybase.onpaint()

Pocket PC is based on Windows CE... WM2003SE is based on CE.NET 4.2, just
as the device I'm testing is.

Paul T.

hi Paul:

[quoted text clipped - 34 lines]

Ed

--
"What if this is as good as it gets?"


Message posted via DotNetMonster.com
http://www.dotnetmonster.com/Uwe/Forums.aspx/dotnet-compact-framework/200508/1

 

[ed via DotNetMonster.com]

Hey Paul:

Very interesting what you've said... I wonder if that's it. so the way
around it is by using invoke?
My project originally started within the windows desktopFW so I never have
these issue, this is interesting. If this is indeed the reason for the code
performance, I'll need to buy you a steak dinner. Can't thank you enough for
yuor continued help. I am reading up on the issue and work around now,
hopefully this will solve my prob. Thanks again.

No, the same .NET CF 1.0SP3 that runs on your PPC2003SE is what's running on
our 4.2-based device with the latest CE components installed. It might have
some different behaviors based on the platform (where tabs on tabbed forms
are), but I think that the basic operations are identical.

The .NET CF is *very* sensitive to calling any GUI-related method from a
non-GUI thread. This has been covered here in the newsgroup over and over
again, along with how to use Invoke to get around it. My first guess is
that you're calling some GUI-thread-only method from another thread.

Paul T.

Paul:

[quoted text clipped - 36 lines]

--
"What if this is as good as it gets?"


Message posted via DotNetMonster.com
http://www.dotnetmonster.com/Uwe/Forums.aspx/dotnet-compact-framework/200508/1

 

[Paul G. Tobey [eMVP]]

It wouldn't just cause things to slow down, if that's what you're seeing,
but it can cause the program to hang. The desktop, apparently, does
something to automatically handle the problem, but the .NET CF does not. I
searched the archives on "refresh thread invoke" and got a manageable list
of articles for you to read. You can search the archives from GoogleGroups
here:

http://groups.google.com/group/micr...tframework?hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8

Paul T.

Hey Paul:

Very interesting what you've said... I wonder if that's it. so the way
around it is by using invoke?
My project originally started within the windows desktopFW so I never have
these issue, this is interesting. If this is indeed the reason for the
code
performance, I'll need to buy you a steak dinner. Can't thank you enough
for
yuor continued help. I am reading up on the issue and work around now,
hopefully this will solve my prob. Thanks again.

No, the same .NET CF 1.0SP3 that runs on your PPC2003SE is what's running
on
our 4.2-based device with the latest CE components installed. It might
have
some different behaviors based on the platform (where tabs on tabbed forms
are), but I think that the basic operations are identical.

The .NET CF is *very* sensitive to calling any GUI-related method from a
non-GUI thread. This has been covered here in the newsgroup over and over
again, along with how to use Invoke to get around it. My first guess is
that you're calling some GUI-thread-only method from another thread.

Paul T.

Paul:

[quoted text clipped - 36 lines]

Ed

--
"What if this is as good as it gets?"


Message posted via DotNetMonster.com
http://www.dotnetmonster.com/Uwe/Forums.aspx/dotnet-compact-framework/200508/1

 

[Chris Tacke, eMVP]

Actually the desktop doesn't do anything for it - it's a bad practice in the
full framework that can still cause a hang (just as it can in unmanaged
code). For some reason the desktop is just a lot more forgiving, allowing
poor code to run without error for longer.

--
Chris Tacke
Co-founder
OpenNETCF.org
Are you using the SDF? Let's do a case study.
Email us at d c s @ o p e n n e t c f . c o m
http://www.opennetcf.org/donate

It wouldn't just cause things to slow down, if that's what you're seeing,
but it can cause the program to hang. The desktop, apparently, does
something to automatically handle the problem, but the .NET CF does not.
I searched the archives on "refresh thread invoke" and got a manageable
list of articles for you to read. You can search the archives from
GoogleGroups here:

http://groups.google.com/group/micr...tframework?hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8

Paul T.

Hey Paul:

Very interesting what you've said... I wonder if that's it. so the way
around it is by using invoke?
My project originally started within the windows desktopFW so I never
have
these issue, this is interesting. If this is indeed the reason for the
code
performance, I'll need to buy you a steak dinner. Can't thank you enough
for
yuor continued help. I am reading up on the issue and work around now,
hopefully this will solve my prob. Thanks again.

No, the same .NET CF 1.0SP3 that runs on your PPC2003SE is what's running
on
our 4.2-based device with the latest CE components installed. It might
have
some different behaviors based on the platform (where tabs on tabbed
forms
are), but I think that the basic operations are identical.

The .NET CF is *very* sensitive to calling any GUI-related method from a
non-GUI thread. This has been covered here in the newsgroup over and
over
again, along with how to use Invoke to get around it. My first guess is
that you're calling some GUI-thread-only method from another thread.

Paul T.

Paul:

[quoted text clipped - 36 lines]

Ed

--
"What if this is as good as it gets?"


Message posted via DotNetMonster.com
http://www.dotnetmonster.com/Uwe/Forums.aspx/dotnet-compact-framework/200508/1

 

[ed via DotNetMonster.com]

Paul And Chris:

Thanks for the replies. I have read some of the online docs about this issue.
basically my update logic should look something like this? :

gui:
display_update(x,y)
me.xx = x
me.yy = y
me.control1.invoke(new event updater)
end

updater()
me.control1.somepropertyx = x
me.control1.somepropertyy = y
end

main:
gui.display_update(x,y)

Does that look right? or do I must create a seperate thread to update it?

It wouldn't just cause things to slow down, if that's what you're seeing,
but it can cause the program to hang. The desktop, apparently, does
something to automatically handle the problem, but the .NET CF does not. I
searched the archives on "refresh thread invoke" and got a manageable list
of articles for you to read. You can search the archives from GoogleGroups
here:

http://groups.google.com/group/micr...tframework?hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8

Paul T.

Hey Paul:

[quoted text clipped - 27 lines]

 

[Chris Tacke, eMVP]

That looks right. If it's frequent, you might use a class-scoped delgate
instead of creating it anew with each call.

--
Chris Tacke
Co-founder
OpenNETCF.org
Are you using the SDF? Let's do a case study.
Email us at d c s @ o p e n n e t c f . c o m
http://www.opennetcf.org/donate

Paul And Chris:

Thanks for the replies. I have read some of the online docs about this
issue.
basically my update logic should look something like this? :

gui:
display_update(x,y)
me.xx = x
me.yy = y
me.control1.invoke(new event updater)
end

updater()
me.control1.somepropertyx = x
me.control1.somepropertyy = y
end

main:
gui.display_update(x,y)

Does that look right? or do I must create a seperate thread to update it?

It wouldn't just cause things to slow down, if that's what you're seeing,
but it can cause the program to hang. The desktop, apparently, does
something to automatically handle the problem, but the .NET CF does not.
I
searched the archives on "refresh thread invoke" and got a manageable list
of articles for you to read. You can search the archives from
GoogleGroups
here:

http://groups.google.com/group/micr...tframework?hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8

Paul T.

Hey Paul:

[quoted text clipped - 27 lines]

Ed

 

[ed via DotNetMonster.com]

now I am confused...

I tried the technique and there must be something that I am still doing wrong.
... here is a view of how my things are setup...

public class calculator
public function calculateValue1() as string
return someString
end
end class

public class api
inherits form
private someString as string
private updaterThing as new EventHandler(updaterMethod)
friends withevents dangLabel as new system.windows.form.label

public writeonly property updateSomeValue as string
set (value as string)
somestring = value
dangLabel.invoke(updaterThing)
danglabel.update() <-------------------------------------------- never got
here
end
end property

private sub updaterMethod(object,eventargs)
dangLabel.text = someString <-------------------------------------- it hangs
here
end sub
end class

module main()
private gui as new api

gui.updateSomeValue = some string to write
end module

I understand that if I am doing gui.property = someStuff the property routine
is executing in the scope of Main(). but I tried enclosing the dangLabel.
invoke within yet another sub and do something like me.invoke(thatOtherSub)
in the gui scope, but it still locks up.

Should I not have used a module as a start_up main?

What could I be doing wrong? Once again, thank you Paul and Chris for all
the help and direction you guys have been giving me.

That looks right. If it's frequent, you might use a class-scoped delgate
instead of creating it anew with each call.

Paul And Chris:

[quoted text clipped - 37 lines]