OK this post is going to sound a bit nebulous but I am a developer on a long established product ( 20 yrs+ ) and it is in the process of being moved from Delphi 5 to Delphi Berlin.
OK this post is going to sound a bit nebulous but I am a developer on a long established product ( 20 yrs+ ) and it is in the process of being moved from Delphi 5 to Delphi Berlin.
This project uses SQL Server as the dataabse and TADO componens to hook to that database ( We will be looking at FireDAC soon )
We have managed to create a working Alpha for a customer.
The executable has gone from 38Mb on Delphi 5 to 95Mb ( x64 ), 78Mb ( x86 ) on Delphi Berlin. The customer is Ok with this, but what they are not OK with is the amount of RAM being used.
When we log in and sit at the front page and do nothing with our Delphi 5 application it consumes 7Mb RAM. If we do the same with our Delphi Berlin version it consumes 15Mb RAM.
As I said this is an issue for our Alpha site. I'd love to just say "Get some new PC's" to our customer, but that won't happen
Does anyone have any ideas of what the additional overhead may be that is causing this consumption.
Sorry for my vagueness, please don't berate me because of it.
Thanks
This project uses SQL Server as the dataabse and TADO componens to hook to that database ( We will be looking at FireDAC soon )
We have managed to create a working Alpha for a customer.
The executable has gone from 38Mb on Delphi 5 to 95Mb ( x64 ), 78Mb ( x86 ) on Delphi Berlin. The customer is Ok with this, but what they are not OK with is the amount of RAM being used.
When we log in and sit at the front page and do nothing with our Delphi 5 application it consumes 7Mb RAM. If we do the same with our Delphi Berlin version it consumes 15Mb RAM.
As I said this is an issue for our Alpha site. I'd love to just say "Get some new PC's" to our customer, but that won't happen
Does anyone have any ideas of what the additional overhead may be that is causing this consumption.
Sorry for my vagueness, please don't berate me because of it.
Thanks
Are you missing a zero somewhere? Because, come on, 15MB? An empty browser tab uses more nowadays.
ReplyDeleteStrings take double the memory because unicode.
RTL/VCL has a bit more overhead because it got more features and probably a few fields here and there (like TObject alone uses a few bytes more).
Different memory manager perhaps (unless you were using FastMM under D5 already)? Is this the real used memory (ask the memory manager itself and don't just look at task manager or process explorer)
what I understand is:
ReplyDelete- Delphi 5, main form, RAM usage 7MB
- Delphi "Berlin", main form, RAM usage 15MB
is my understanding correct?
what about the RAM usage after normal operations, is it still double? because if on avg you have 7MB of RAM more on "Berlin" than on Delphi 5, it isn't that much, and if it is, the PC's are most likely using SWAP already, so, again, not a big deal, if I understand correctly, of course...
15MB of RAM wasn't an issue when D5 was the current version. Why the hell is it an issue today?
ReplyDeleteYou need to educate the client that 15MB is nothing.
ReplyDelete/sub :)
ReplyDeleteRichard Baroniunas I assume it's some industrial hardware that's 128/256 MB of RAM and has many things running, if that's the case, it's already swapping a lot, so... better start doing some C (;
ReplyDeleteAs others have suggested, I don't think your metrics are necessarily meaningful. The footprint of a form loaded into memory is pretty much irrelevant unless it's the only form in the app and it's not allocating any significant data on the heap or stack while it's running. It also implies there are no memory leaks anywhere, which is pretty hard to fathom.
ReplyDeleteIn my mind, the only thing "nebulous" about what you're asking is why you'd think that the code produced by a platform nearly 20 releases later should have the same memory footprint as the original version.
If this is running on some embedded hardware with immutable limitations on RAM, CPU bandwidth, and storage, then you're probably best to stick with D5, if for no other reason than for stability.
The latest versions of Delphi are designed to support environments where 8-16GB of RAM are fairly typical, so 7MB is "noise". (It's 0.7% of one GB) Cell phones with <4GB seem to be highly constrained today. Even mobile apps smaller than 20MB are hard to come by.
I think your focus is misplaced. If there's something in the latest version(s) of Delphi that you absolutely need now, then it may be time for your clients to revisit their overall system requirements as well.
(Why exactly are you looking at migrating to Berlin now, anyway?)
So little memory?
ReplyDeleteThat RAM consumption should probably be the least of the worries of that customer, IMO. Otherwise, David Schwartz sums it up well.
ReplyDeleteDavid Schwartz "(Why exactly are you looking at migrating to Berlin now, anyway?)"
ReplyDeleteOktoberfest?
>As I said this is an issue for our Alpha site. I'd love to just say "Get
ReplyDelete>some new PC's" to our customer, but that won't happen
They'll pay the developer time/salary to port from 5 to Berlin, but not to add some more RAM to a PC?
As others have indicated; starting such a project in the first place makes no sense, if there are such severe restrictions on the hardware resources available. It sounds as though you should rather go further back in time to even leaner compilers. :P
ReplyDeleteAny computer where 8 megs of ram is a problem is probably INCAPABLE OF BROWSING THE WEB. WHAT IS THEIR PROBLEM?
ReplyDeleteGiven the constraints, it's probably some kind of embedded system built with hardware designed around 2000 or so, like a kiosk or a POS device or something like that. Not doing web surfing.
ReplyDeleteWhat OS is it running? Win XP? (I'd never use Windows on an embedded system, although I know it WAS used a LOT for that purpose. People got round its general instabilities by having it auto-reboot once or twice a day.)
David Schwartz „...I know it WAS used a LOT for that...¯
ReplyDeleteit still is, especially the windows 7 and 8 tablets that were dirt cheap, just wrap them in a box and they're good to go!
Asbjørn Heid because our client is running on low spec kit and it would work with 5 copies of the EXE open and running on the old version; but it won't on the new! I WISH I could convince them that they are being unreasonable, but in their defence they have 90+ PC's on this low spec, so that would be a lot of cash they would have to outlay !
ReplyDeleteTo those people that have asked / speculated. It's actually not an embedded application. It's an ERP application, but most of our customers have very low spec'd machines, such as Core i3 with 4Gb RAM or even lower with 2Gb RAM and they expect/need this large ERP application (150+ forms) to run in those memory spaces, but not only that they expect to have several copies open.
ReplyDeleteTony Danby that's definitely pre-XP era...
ReplyDelete15MB goes into 2GB many times. Doesn't really sound like you have fully diagnosed the issues.
ReplyDelete2Gb ram should be sufficient to run 5 instances of a 15Mb .exe without breaking sweat. However - a 15Mb .exe says NOTHING about the footprint of the running .exe. IMO, it is not the .exe size that is the problem here, but how memory is managed by the application. Have you changed the memory footprint somehow? Switching to Unicode will double the footprint for text. Are there ways to free out forms and frames (or window handles) that are currently not visible to reduce the footprint?
ReplyDeleteThe system will swap out anything that is not currently being used, so I think it is very premature to suggest solutions before a problem has been clearly identified. Don't throw trial and error at this problem. Understand it.
ReplyDeleteLars Fosdal, David Heffernan Guys, we are correctly creating and freeing our forms on the fly, this is not the issue. To be brutal and blunt, the customer will not stick their hand in their pockets to fork out for modern kit to run this application on. Lars Fosdal As this application is UK only and the database uses VARCHAR and not NVARCHAR it *might" be a consideration to switch off UniCode, but we have hunted high and low for that optimisation. Does Delphi Berlin have the ability to switch it off or ( as I suspect more likely ) is UniCode so "baked" into the compiler this is no longer possible?
ReplyDeleteTony Danby No, all versions of Delphi since 2009, are Unicode inside by default (string, char, pchar), and trying to work around that will probably be a major bit of work. I still find it strange that you can't run 5 instances at the same time on a 2Gb computer. XP takes around 800Mb if I remember correctly What is the typical memory footprint of the application once it has loaded it's data? Does the footprint stay stable over time?
ReplyDeleteI don't believe that you have diagnosed your problem correctly. This smells like there is some wishful thinking that the problem is down to the machine's memory.
ReplyDeleteLikely the client is loading the machines up with other software as well, and have upgraded the machines to Windows 10 (Tony Danby, there is no mention of the actual OS in your posts that I can see?)
ReplyDeleteDavid Heffernan is correct, more details and diagnosing is needed before any real recommendations can be given, or its just throwing darts wearing a blindfold.
Tony Danby - Off topic, but - if you are going for FireDAC, I recommend installing SQLNCLI on the client computers.
ReplyDeleteDavid Heffernan I can't diagnose it any further ! Wish I could, but this is the customer reporting this and we have to "be seen" to respond and this is all the information we received from them despite repeated requests for more. I know for a fact they are running "other" applications that they deem necessary but then wont elaborate on that point either !
ReplyDeleteTony Danby I see no other way out of your predicament than sticking to the Delphi 5 version then, if that "works for the customer" (well... my guess is that it actually doesn't).
ReplyDeleteAre they at least willing to let you investigate on one of their machines via TeamViewer or similar? That would be the last straw; if they are not cooperating at all in the effort to figure out the supposed problem they are reporting... they may quickly find themselves ex customers :P
Tony Danby What are the exact symptoms of behavior when you run five copies? Is there a distinct difference between four and five copies? What is the memory load when running five instances? Is there a swap file? Is it large enough? What error messages do you get - if any? Is there any inter-instance communication? Is there any use of system objects that may have changed between D5 and Berlin?
ReplyDeleteNvm, I just saw your other comment about customer not providing more info. That seems a bit strange of an attitude from the customer's side. Is there someone else that is trying to muscle in and replace your app?
ReplyDeleteLars Fosdal Nope ! No one trying to muscle in, they are just being belligerent as I undestand it and the "IT guy" there is a possibly not as proficient as you or I ( that's the subtle/nice way of saying it )
ReplyDeleteIt look like the problem might not be memory, but handles/resources due to a 3rd party library we are using. Results of our testing will be published (abridged ) here. If anyone is interested then just /sub this post
ReplyDelete/sub
ReplyDeleteTony Danby Fire your client, they are idiots.
ReplyDelete