David,
I agree with what Hannah has written above. Here's what I've seen surrounding this particular type of issue.
There is a general bug or two which have been logged that encompass the many parts to this one issue. It is necessary, however, to look into the smaller components that feed that issue. All of these come back to two mainly two things (1) the microsoft sql compact edition database and (2) limitation of processing power on most mobile devices.
CQ00312809: Errors are received when adding a large number of layers to ArcPad on a mobile device
CQ00313039: 7+ schema-only feature classes checked out for disconnected editing produce low memory errors on mobile devices
1. Having many feature classes checked out for disconnected editing is taxing on the processing power of those mobile devices. Even if they are schema-only and small in disk size, they can still utilize a lot of the memory of the device. I've seen this same behavior in different datasets ranging from 8-50 feature classes, the average number at which I see memory issues arise is in the late teens, early twenties. Limiting the number of feature classes that are available for that particular project (having multiple maps for different crews or projects is a good practice to follow) is the best way to reduce this issue.
2. If your feature classes have many domains specified this can cause a performance issue. The same functionality via dbf look up tables does not cause the same behavior.
CQ00312880: Poor performance in ArcPad 10.0 SP2 opening edit forms for AXF with many domains
3. The number of fields in your table (hundreds) can sometimes cause an issue.
The best way to handle this behavior is to turn off the visibility of fields which your field crew doesn't really need via the Fields tab of the Layer Properties of a feature class in ArcMap. Then during the checkout process, make sure that you check the box for "only take visible fields".
4. You mention relationship classes. This is another thing that's been documented as contributing to low memory errors.
CQ00312879: Performance is severely degraded when utilizing multiple relationship classes within an axf on a mobile device.
I've not seen this issue creep up until perhaps 15-20 tables are in the document. This, in-turn, often means that there are many feature classes in the document as well.
5. Background shapefiles perform better than background axf files. If you don't mind sending your background non-editable layers out to shapefile this will help improve performance. I know you said you only have one simple street shapefile, but I would still use the process of elimination to make sure that it's not contributing to the problem.
6. Use definition queries to limit the amount of data that's drawn on the screen. Either send your def queries out via the checkout process or perhaps create custom buttons which will limit the features that are drawn at one time. The following snippet will get you to where you need to be to set the queries via vbscript.
Application.Map.Layers("MyFeatureClass").Filter = "FIELDNAME = 'Test'"
The "FIELDNAME = 'Test'" that you see above is the same thing you would see in the Filter tab of the Layer Properties via the ArcPad Table of Contents.
7. Reverting from 10SP3 to 10.0.0 will most likely not cause a difference in this behavior. This is an artifact of axf files, not so much the current version of ArcPad. There were quite a few fix issues in SP3 (10.0.3) and I would recommend using this newest version.
All in all, testing, troubleshooting, and using the process of elimination should work to get to the specifics of this issue in relation to the points above. The quickest way to see these issues diminish would be to limit the number of feature classes in the document.
