I started a new job a few months ago where the whole business relies on Delphi 7-built applications and interfaces to external systems and partners. A lot of 3rd party components are used, such as the whole DevExpress library, Indy, TMS components, Turbopower, SDAC, and many more, for a total of about 20.
This is the state of things and none of it can be changed (the company has over 1000 employees).
Now, compiling their main application takes around 7 minutes and has over 2M lines of code. All the workstations run on VMWare, which might account for part of the compile time. This compile time is the same, even when server/network load is minimal at night.
Changing a single line of code will cause a simple compile to take 4 to 5 minutes, even if nothing else changed. I cannot use code completion or code parameters is impractical as it incurs a delay about as long as a compile.
Is there anything I could do to improve compile time? I ran some ideas by the manager, and DLLs or any type of external dependencies are out of the question. Upgrading to a newer version of Delphi is out of the question as they estimated that cost to over half a million dollars, and they plan to do that at a much later date.
Someone mentioned putting all 3rd party files in their own separate packages since they never change, but I'm not experienced with packages enough to know if that would help compile times.
I did some searching over the last few weeks, but I did not find any ideas that would apply to my situation.
Thanks in advance for any tips!
PS: I need to add that I tried DelphiSpeedUp and other tools with no help in compile times.
Related
I have an old Delphi application and i want to migrate it to the newest Delphi version. The problem is that the application is huge and migrating whole app at once would be too complex. I wonder what is the best approach to do this... Maybe form by form, placing a form into a dll and then using older forms in the new Delphi app and replacing them one by one (after clients confirm one form is working ok to continue with the next one). Not sure if this would be possible at all...Any other ideas?
I presume that based on your comments you do not have comprehensive test cases. In that case, you are simply in a world of pain, and there is nothing that will truly mitigate that. Without test cases, any approach you take will generate errors and bugs that will take you quite a while to catch them all. Build that into your expectations. In fact, with those as your expectations then you need to schedule a large testing phase and maybe that is a good approach. Upgrade all at once and test over the course of a few months.
You could first identify all 3rd party components that will eventually be needed and upgrade them to the latest version one at a time. That way you can at least identify bugs in a controlled manner per 3rd party component. Again, since you are relying on manual testing, this also will be error prone, but maybe you can focus on areas that use the upgraded component preferentially.
here my advice.
Before you start migrate, do a refactoring of your existing source-base.
1.) Remove un-used stuff.
2.) Try to move as much as possible to standard delphi components.
3.) Remove "un-used" units from your uses-statements.
4.) If needed, try to do some layering (App-UI,App-Logik,DB-Layer,Libraries)
5.) Look for 3rd-Party Components/Libraries, which might be not needed anymore in the latest Delphi Version, because the functionallity is now included in Delphi. If you spot such components/libraries, try to encapsulate them.
Now you have a new version of your software (still in the old delphi). Test it as exact as possible (Unit-Tests would be perfect).
If this is done, then you start to migrate to newer Delphi. I recommend to do it in one go (instead of dll and one by one).
I do not think there is enough information presented to give you specific advice.
My answer would be to bring in knowledgeable experts to look at your code, talk to your staff, look over your documentation and tests, and then present you with smart options. This can likely all be done via Zoom/Skype online. If you think about how much money you are going to end up spending on the conversion, and how much money you will spend on fixing problems because you went off in the wrong direction (and how many customers you could lose due to bugs/performance issues) this would be an extremely cheap investment.
There are a number of firms with Delphi experience that could help you. (I do not work for one and this is not an ad.) There are some well-known Delphi consultants that would likely have some free, or small flat-fee type, initial conversation.
If you are using a version before the Unicode switch in Delphi 2009, there are a number of online resources to assist. Delphi Conversion Unicode Issues
If you want some real-time advice and chatting about specific issues, check out a Telegram server dedicated to Delphi programming with nearly 800 members. There are nearly always some Delphi experts online answering questions. https://t.me/delphidevelopers You should be able to get some consultancy contacts from that server.
When I worked with Delphi 5 I always pressed F1 on a method I did not knew how to use. The Help system explained what it is, what is does and gave an example on how to use it in a simple code. After that I installed Delphi 2006 and bammm! No more code examples.Anyone knows why give up on something so important?
(Personal opinion based on observation and analysis of a long time Delphi user, as I am not from Delphi team. If you do have any evidence to support or challenge, please leave a comment.)
Delphi 5/6/7 help system was built upon a Microsoft Help system called WinHelp.
Due to Microsoft's decision to make WinHelp obsolete, all previous help materials become "impossible" to migrate (need more info from Embarcadero to support this statement). The new help system in Delphi 8-XE 3 was a completely new system. Porting contents and formats from the ancient platform to the new one becomes a huge burden and a very time consuming process, which takes many years to accomplish.
Delphi 2006 was an "intermediate" release, where its help system is half baked. You have to use a later release (such as the latest) to get F1 working as you wished. Or alternatively, use the online version, such as
http://docwiki.embarcadero.com/RADStudio/en/Delphi_Reference
There are a huge number of components that come with Delphi (XE2), many have been around for along time. Which components should be avoided (the BDE Components for instance), which are out of date (TXPManifest?), and which should be avoided because they are unusable or will just cause grief?
Anything for which you don't have the source. Nothing says "frustrate me" more than not being able to figure out why a component is behaving the way it is because it's poorly documented and being stuck on an old Delphi version because I can't recompile it.
Anything you don't absolutely need.
I am currently maintaining a large application that is dependent on a variety of 3rd party components. In order to upgrade the application, you need to upgrade the components. In the case of vendors that are no longer in business, that's a problem. As a result the entire application is stuck in limbo.
I am looking at Quartz.Net and it seems to be almost a year ago.
I am wondering if they stopped development on it or it the next versions is just taking a while to do?
I am asking this because I really don't like to invest time in something that is at the end of its life or not being developed on anymore because I just know in the future I going to have to upgrade to something different so might as well just start with something else.
Of course whatever I choose might not be developed on in the future either but I like to see new versions to be a few months within the time I start to use that product.
If it is dead anyone have any other alternatives that are being still worked on and have the same features as Quartz?
Quartz.NET development hasn't stopped at all, it just moved to github. If you check the source repository at sourceforge, the last commit was 4 months ago and it clearly says "Source moved to GitHub, removing trunk as it's misleading at the moment".
The github repository has currently 28 watchers and 8 forks, and active contributors (i.e. it's not a one-man show) so the project is definitely not going to die any time soon.
By the way, the latest release was 1.0.3 (August 2010), at the time of this writing this is much less than a year ago.
Quartz.net is actually very active. I've written to #lahma a couple of time for bugs and he fixed it in a very short time.
A couple of months ago I had tried the 2.0 and it was a little bit buggy.
I know there's a new API. You might give it a go.
If you've purchased the Software Assurance, can you please share your experience? Was it worthwhile?
I vaguely remember reading some negative comments about SA maybe 1 or 2 years ago.
If you normally upgrade each time a new version of Delphi is released, SA is great. It's slightly cheaper than the upgrade pricing, you get the new software right away (no wait for purchasing/ordering), and you get a couple of support incidents thrown in. It also makes it much easier for those of us who have to go through an annual budget battle; you know ahead of time what you'll need to budget per developer for the next year for Delphi updates, instead of having to wait until the version is actually released and then fight for the money.
We've had about the same track record as mj2008, starting with D2007. We bought SA for RAD Studio and not just Delphi, so we also got Prism when it was introduced into RAD Studion 2009 and updated with RAD Studio 2010. (And of course, C++ Builder is thrown in as well.)
I bought SA for D2007, renewed twice, and have had D2009 and D2010 for my troubles.
I think it makes it worth it for me, as I have less to think about and get the software when it comes out.
I agree with Ken. If you intend to upgrade to each new version, SA costs less than upgrading. More so for Enterprise and Architect SKUs than Professional.
SA makes the most sense in the long run. If the goal is to simply get the next release "free", then SA is going to be a gamble.
You can look at Delphi's release history to make an educated guess about future releases and do the math for yourself.
I've used SA in one form or another since Delphi 7, and my experience has been mixed. The worst single screw-up was the release that happened while the development teams were transitioning to CodeGear. In their defense, a lot of people worked hard to sort everything out, but it really was a mess. Since then, it's gotten much better. For the last two releases, I received my SA notice with download instructions within about a day of the RTM announcement. Much better turn around time than the Windows 7 release with my MSDN subscription.