Hi

One of the characteristics of llblgenpro is that it consume a massive amount of memory. (Especially on 64-bit).

This is mostly because each object has an array of "llblgenprofields" that contain a boxed "boolean". I know it has advantages, but the downside is that I'm currently developing software for tablet windows 8 and I'm a bit scared...

I'm scared because I do keep the objects a long time in memory. I have my own caching mechanisme, since I always work on a small subset of data. (Typical for the product).

Are there any plans to check/change/think about the memory consumption of the framework? I know memory gets cheaper, but somethimes it is just impossible to upgrade.

Thanks

Alexander

Alexander wrote:

Hi

One of the characteristics of llblgenpro is that it consume a massive amount of memory. (Especially on 64-bit).

This is mostly because each object has an array of "llblgenprofields" that contain a boxed "boolean". I know it has advantages, but the downside is that I'm currently developing software for tablet windows 8 and I'm a bit scared...

What property/field are you referring to as a boxed boolean? All values are boxed, indeed... We tried a lot of things to bring down memory usage, but in the end it's the object structure that's causing the memory pressure: the field objects themselves inside an array take more memory than normal members. .NET isn't very friendly for these structures, and takes more memory than you'd expect.

I'm scared because I do keep the objects a long time in memory. I have my own caching mechanisme, since I always work on a small subset of data. (Typical for the product).

Are there any plans to check/change/think about the memory consumption of the framework? I know memory gets cheaper, but somethimes it is just impossible to upgrade.

We try with every new version what we can do about performance and memory consumption. I don't know what else to try in entities to lower the memory pressure, other than to go a drastic route and get rid of the Fields object. This will break a lot of code, so we thought about making 'Fields' something that's constructed on the fly when you need it, but this will need so much refactoring that it's not really worth it. The main issue is that .NET itself eats much more memory than you'd do when using C++ for example.

The tablet software, if you use metro/winrt, you can't use ADO.NET, so it will require accessing a service, correct? It could be beneficial to use WCF Ria services in this case: this service creates silverlight entities with change tracking for you to be used on the client, and on the server you can use llblgen pro code.

next version (v3.5) will also have support for WCF Data services, which takes 10 lines of code to enable the service on your generated code so you can consume it on a restricted platform, e.g. a tablet.

Would that work?

Hi

Yes I'm aware that most of the memory is caused by the "overhead" of objects in .net. The real problem is that this is massive. Especially on 64-bit, I cannot explain this to my customers.

You are also very right when you mention that the only option you see is to get rid of the "fields". This is also the only option I could think of, but dodging this approach is maybe something that was already "under consideration". That is why I'm asking it. Now i solve it myself by doing db access using llblgen and "transforming" it to poco objects inside cache. A lot of work though and it would be uberawesome if llblgenpro 4 would have a tiny footprint.

As for the windows 8 / tablets stuff. I didn't gave it a second thought yet. MS promised "us" that everything that works on W7 also works on W8. And I'm still under the assumption that they should make it possible to compile and run any managed net app. If it would not be possible to run our apps that we are developing today on windows 8, then now is a good time to switch back to os2 warp ;-)

Thanks

A

Alexander wrote:

Hi

Yes I'm aware that most of the memory is caused by the "overhead" of objects in .net. The real problem is that this is massive. Especially on 64-bit, I cannot explain this to my customers.

It might eat a bit of memory, but it doesn't consume gigabytes of memory in normal usage. Unless you cache a lot of data of course (but why would you, the database already does that too, it only is more efficient if the db is accessed over the network).

You are also very right when you mention that the only option you see is to get rid of the "fields". This is also the only option I could think of, but dodging this approach is maybe something that was already "under consideration". That is why I'm asking it. Now i solve it myself by doing db access using llblgen and "transforming" it to poco objects inside cache. A lot of work though and it would be uberawesome if llblgenpro 4 would have a tiny footprint.

The transformation to DTO's and back can be done with code you generate (there are several DTO templates on this forum, do a search on 'DTO templates'), it's more about 'why do I need to do that?' and I agree it would have been better if entities wouldn't have to carry around field objects. We toyed with several solutions, but all have drawbacks which IMHO are not acceptable. For example, we could replace the fields with an object array, and some state flags, mitigating the fact you need to have field objects. The downside is that replacing / obtaining a field object isn't that great in that scenario. Also, the gained advantage wasn't that much that we decided to leave it as-is. The best way to deal with this would be to have normal members, and the 'Fields' object would be a facade. However as I said above, that would mean our framework has to be changed so it would address these members directly, as working with the facade object would be overhead which costs performance while it can be avoided.

As for the windows 8 / tablets stuff. I didn't gave it a second thought yet. MS promised "us" that everything that works on W7 also works on W8. And I'm still under the assumption that they should make it possible to compile and run any managed net app. If it would not be possible to run our apps that we are developing today on windows 8, then now is a good time to switch back to os2 warp ;-)

haha I remember those days I was the only one in the company I worked at back then who ran OS/2 warp, as I refused to surrender to 'windows'. I lost.

Anyway, it depends what you want to achieve: on windows 8, if you want to have a metro-style app, with touch and all, your app runs on WinRT. WinRT doesn't have any data-access libraries, and a limited .NET runtime. This means you can't simply run our entities on it nor can you access a DB. The 'designed' way to work with data in that scenario seems to be to access a service, e.g. a WCF data service/ria service. The classes you get from these services are dumb DTOs, but the service logic has change tracking so it's not that bad. The server side is picked up by our framework and it takes 10-20 lines of code to set this up.

If you want to have a normal application like on Windows 7, so no touch awareness, or at least, not optimized for touch, you can run a normal .NET application on the normal 'desktop' on windows 8. The downside of that is that on a tablet you really don't want this.

I'd go for metro + service access in your case.