Memory hog - my app and SQLCE

  • Thread starter Thread starter davecline
  • Start date Start date
D

davecline

Tribe,
Reviewing the "Settings/Memory/Program/Free" I'm seeing 13 MB after a
soft reset of the Treo700w emulator. Groovy.

I start, say, Outlook (messaging) and it drops a meg. Hey that's nice.

I start my tiny, 1 form cf 2.0 app that has 4 small custom dlls in it
and also a reference to a SQLce SDF db and Free memory drops to 3 MB.
Schiezten! (Tribe for Oh Dear!)

Is CE this much of a pig? Or is it .NET 2.0? or what? Running this on a
Treo700w which means I have to put the cf 2.0 on there (as 1.0 is
essentially useless).

Is this the footprint I should expect for all NET cf 2.0 + SQLce apps?
6+ MB on this already memory challenged WM 5.0 device? You'd think
MicroPalm would give you more than 13 MB ram to play with on a such an
advanced device... NOT.

Thanks,
Dave Cline
~bangeye~
 
Uh, yeah, so there's two? There's probably 10 right?

Reference: System.Data.SqlServerCe
Runtime Version v2.0.50129 (must be the CF version eh?)
Version 3.0.36000.0
/SmartDevices/SDK/SQL Server/Mobile/v3.0/System.Data.SqlServerCe.dll

Thanks,
Dave Cline
 
Ok, that's SQL Mobile then. I'll do some testing on a Treo I just got and
see if I can find out anything.
 
I've done some research in to memory usage in CF 2.0 and SQLCE (mobile
I'm told).

Here are my findings for future reference. All tests done in the
Verizon Treo700w emulator, done here as this will be a most popular
platform if the Treo650 is any indication.

I left FileExplorer open so I could click launch the simple app. I
Start/System/Memory to view the Program-Free.

The numbers you see are all Program-Free MB.

Test 1: a simple cf2.0 winform app with one button.
No other references: size 5.5k
a)
Post Soft reset (+FileExplorer): 10.74 MB
Post open: 8.16 MB
Post close: 10.74 MB
b)
Post open: 8.16 MB
Post close: 10.74 MB

Just to start .NETcf2.0 takes about 2.58 MB

Test 2: same form with a reference to SQLCE 3.0.36 (see above message)
No code - just the reference.
a)
Pre: 10.47
Post open: 7.88
Post close: 10.46
b)
Post open: 7.88
Post close: 10.46

Result: so we have a total memory usage of : 2.58 - no change.

--- (Soft Reset Here) ---

Test 3: I added the construction of an SDF and a open connection (see
code below)
a)
Pre: 11.73
Post open: 8.03
Post Conn open: 6.50
Post close: 11.45
b)
Post open: 7.99
Post Conn open: 6.49
Post close: 11.44
c)
Post open: 7.99
Post Conn open: 6.49
Post close: 11.44
d)
Post open: 7.98
Post Conn open: 6.48
Post close: 11.43
e)
Post open: 7.97
Post Conn open: 6.47
Post close: 11.43
f)
Post open: 7.97
Post Conn open: 6.47
Post close: 11.43

+ 5 more iterations Post close: 11.43 - NO LEAKING

Result: Before the database is opened, memory usage: 3.46 MB and
additional 880k for SQLce. And with the connection opened - no datasets
no dataadapters just the connection: 1.5 MB. That is, just opening the
connection to an SDF sucks up 1.5 meg of RAM.

So before you write a line of code to do ANY presentation or data
manipulation you burn up 4.96 MB of ram just running .NET cf 2.0 and
the SQLCE mobile edition.

5 meg GONE before you even start.

That sucks. Maybe CF 1.0 and some other data management scheme is worth
pursuing. What other data mgmt options do I have?

Data SDF creation, connection opening code used:
//////////////////
public partial class Form1 : Form
{
public SqlCeConnection DatabaseConn;

public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
string connStr1 = "Data Source=test.sdf;password=bingo;encrypt
database=TRUE";
string connStr2 = "Data Source=test.sdf;password=bingo;";
SqlCeEngine dbEngine;

try
{
System.IO.File.Delete("test.sdf");
dbEngine = new SqlCeEngine(connStr1);
dbEngine.CreateDatabase();
dbEngine.Dispose();
DatabaseConn = new SqlCeConnection(connStr2);
DatabaseConn.Open();
}
catch (IOException ie)
{
MessageBox.Show("IO:" + ie.Message);
}
catch (Exception ex)
{
MessageBox.Show("Other:" + ex.Message);
}

}

private void Form1_Closing(object sender, CancelEventArgs e)
{
if (DatabaseConn == null)
return;
if (DatabaseConn.State == System.Data.ConnectionState.Open)
DatabaseConn.Close();
}
}
//////////////////

Regards,
Dave Cline
~bangeye~
 
Dave,

I wouldn't myself be worried by the memory consumption you're seeing, since
adding more managed code isn't going to bulk up your app like unmanaged code
would. The only thing to really watch for would be leaks, which you are not
seeing. If space gets tight, using a storage card for the data would
certainly be an option, and using SQL Mobile gives you the option to encrypt
your data so if the storage card is removed, the data is still safe from
unauthorized use.

Still there are other data options that don't involve the 2+ Mb hit of SQL
Mobile. I'd recommend CSV files as the best text file format (as opposed to
XML) since it takes us less space on the device and it's quicker to parse.
There is a TextDataAdapter on www.opennetcf.org that makes working with CSV
files very easy and the amount of code is tiny - you don't need the entire
OpenNETCF SDF library unless you want it. The downside is that
encrypting/decrypting those files (if that matters to you) is another step,
and you lose the ability to use SQL syntax, ACID transactions, and the other
things advantages of a real SQL database. A final downside if you're
capturing a lot of transactions is that updates require rewriting the entire
file if you use DataSet.Update to do them, although you could alternatively
store and manage your data once you've parsed the file as a collection of
business objects and just append new data to the file as it's collected.

Halfway between CSV and SQL Mobile would be SQLite, an open source project:
http://sqlite.phxsoftware.com/ It takes up about a half Mb on the device not
counting data, but as you might expect it is much less full-featured than
SQL Mobile. It does support SQL syntax. You might like SQLite for a variety
of reasons, but saving only a couple Mb on a modern device wouldn't sway my
decision.

HTH,
 
What's your point of reference? Are you comparing to applications in, say,
1980? If so, please factor in Moore's law which would translate 6MB today to
about 200 bytes equivalent in 1980.

If you're comparing with desktop, you would see device application uses
about 10% as much memory as average desktop application which could easily
take out 40 MB and have even more swapped out.



It's 2006; today's code is very high level and uses a lot of memory
providing huge amount of functionality per line of code.

You can load data from SQL Server and show it in data grid in 5 minutes
without any coding at all. Same task would probably take you a year to
implement in 1980, not to mention you would probably need some powerful
mainframe for that.



Yes, modern software uses a lot of resources. That's not a secret and that's
the way development been heading for years.

I know embedded developers were sort of left behind (I used to program for
i8x51 with 128 bytes RAM myself), so I suspect that's why you shocked to
find out device application can use megabytes.



Anyway, the real issue here is: some manufacturers in 2006 are managing to
produce devices with less available memory than first iPaqs 6 years ago to
save some $3 worth of RAM chip.

Should you have meager 64 MB of free RAM, 6 MB would not be an issue at all.


--
Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
Sadly, you're not going to get much better than that even with an alternate
database. Here was a similar test I ran using the ADO.NET 2.0 provider for
SQLite:

Program memory before (using WM2005 emulator)
18.49mb

1 Form with an exit menu item, no reference to SQLite or ADO.NET or anything
else but Windows.Forms:
15.76mb

Same as above, except creating a DataTableMapping() object so as to
reference System.Data:
15.09mb

No DataTableMapping this time (ADO.NET is referenced here so it is
unnecessary), and creating a SQLiteConnection but not opening it:
14.74mb

Same as above, except opening the connection:
14.32mb

Robert
 
Ginny Caughey said:
Halfway between CSV and SQL Mobile would be SQLite, an open source
project: http://sqlite.phxsoftware.com/ It takes up about a half Mb on the
device not counting data, but as you might expect it is much less
full-featured than SQL Mobile. It does support SQL syntax. You might like
SQLite for a variety of reasons, but saving only a couple Mb on a modern
device wouldn't sway my decision.
Click to expand...

SQLite's only halfway? Ouch! :)

Robert
 
Robert,

You're right, that's probably not fair because it does have a lot of
functionality. Make that "Somewhere between CSV and SQL Mobile..." ;-)
 
All,
Thanks for taking the time to work with this information.

IIya, yeah I'm shocked. I've got 1/2 a gig of RAM to work with on my
servers. What's so tough about putting workable ram on something the
size of a ice cream sandwich? I mean, look at these thumbnail sized 1
gig USB drives. These "Smart" device guys have no excuse.

Robert, I went and found and downloaded and used your wonderful efforts
which come in the shape of SQLite for CF2.0. Excellent example of
OpenSauce.

Here's my numbers in the same refererence as above:

Pre open: 11.49 MB
Post open: 8.17 MB
( 2.79 )
Post conn open: 7.83 MB
( 0.34 )

So 3.13 MB for SQLite compared to 5 MB for SQLCE (.net cf 2 in there
too of course).

Is almost 2 meg worth saving on something that, after I get all my
data, contacts, UI and supporting crap into these applications, may
only have ~ 4 meg left - I say hell yes it's worth it!

Ginny, thanks for your analytical words. As a MVP maybe you can convice
Bill to not only cure tuberculosis but also cure all the bloat in MS's
software... Sorry, that last wasn't fair. SQLCE I'm sure is great for a
CE device that has a bunch more RAM room. But these silly Treo's, well,
let's just say I have a healthier respect for Palm's PDB format.

Thanks again all,
Dave Cline
 
Back
Top