02-03-2009 07:20 AM
I have not yet installed iTunes for that very reason.
I am however also using Agendus for Outlook which I installed after ACT and I believe that the OL process remained active even before the Agendus install.
02-03-2009 07:29 AM - edited 02-03-2009 07:30 AM
Taken from MSDN:
<here is where I would have copied/pasted part of the article, but the board won't allow it b/c it contains HTML>
Message Edited by Default on 02-03-2009 07:29 AM
02-03-2009 08:07 AM
Intersting information. Thank you.
I am actually still running Office 2003, so perhaps I should try the latest Outlook 2007 eval when I can summon the energy.
(I apologize for any hijacking concerns from the original thread)
02-03-2009 10:38 PM
I just upgraded to Act 2009 and have used it for less than a week. I run it on XP Home with a P4, 3.16 Ghz laptop w/1.25 gig ram along with Outlook 2003 open and occasionally Excel and IE7 too. I also run it on Vista Home Premium laptop with an Intel T5800 Core 2 Duo Centrino, 2.0 Ghz, w/3.0 gig ram with Outlook 2007 open. The Vista machine is my travel laptop, so I don't spend as much time on that machine. I have about 1700 contacts. Lookups are slower on the P4 machine, but not too obnoxious for me. Occasionally it doesn't draw the entire lookup box for some reason, but I hit the escape key and try again with no problem second time around. Not nearly as fast as Act 6 or Act (DOS) version that I have used in the past. I like some of the new features, especially the Outlook integration for attaching sent emails. I upgraded based on a couple of online reviews I read. It's been interesting reading some of the posts regarding speed and I have to admit, I need to spend more time with the new version before I decide to keep it. I hope this info helps.
02-04-2009 07:48 AM
02-18-2009 03:34 PM - last edited on 02-19-2009 05:50 AM by dlunceford
We have a server computer based on Core 2 Quad (Q6600), 4 GB RAM, SQL Express 2005, Small Business Server 2003.
We also have a workstation based on Core 2 Duo (E7300),2 GB RAM, SQL Express 2005,Windows XP SP3
Act 6.0 database size was below 20 MB, Act 2009 upgraded database size is about 87 MB after all possible maintenance steps done, history older than 60 days removed.
In order to open up the database from the workstation you have to wait for about 8 minutes. Tech support blames it on XP SP3. Fine, let's remove the latest security update from Microsoft and go back to SP2. The result is: 1 minute load time - still outrageous. Our network consists of 5 computers and features 1 gbit connection.
Back in 1998 I wrote a custom database software for phone call accounting (using Borland Delphi). It had to deal with 500 000 records minimum and was supposed to handle duplicities when adding to the database. Those who understand databases surely know that checking for duplicities when adding another 200 000 records to the database is a very VERY ugly thing. By using 2 levels of hash tables and one binary tree this ran on 100MHz 486 machine with 128 MB of RAM and Windows NT 4.0 so fast, that the above operation took right below 30 seconds.
Today you got 4 cores, thousands of GHz, 2+ GB of RAM and there's issues with 5000 records in a database. That is a blasphemy of the worst kind. Even if they wrote the whole thing in a Visual Basic it must have really taken a determination to make it that slow.
Obviously my client refused to use this software and we'll have to return it.
Have a good day.
<Please post courteously.>
02-18-2009 06:03 PM - last edited on 02-19-2009 05:51 AM by dlunceford
To continue my thought regarding the hard drive speeds:
It takes around 3 seconds to copy the 87 MB file from one folder on my hard drive to another folder of the same hard drive in my computer (I said COPY, not MOVE).Right after the file was read for the first time, the Windows operating system has it in the cache memory so that next time it doesn't have to read it from the hard drive again. Typical SATA drive gives you reading speeds somewhere between 60 - 80 Megabytes per second. That slow 4200 RPM drive gives us perhaps 20 - 30 Megabytes per second. Since the file is below 100 MB of size and Windows does the drive caching anyway, you can see how much sense the hard drive RPM suggestion makes. Not much. The only thing that is to blame is inefficient coding. I'd be happy if someone convinced me it is something else.
<Please post courteously.>
02-19-2009 09:44 AM
With all due respect, you have several misconceptions about how data is stored and retrieved from hard drive. As a point of qualification, I spent several years doing design tech support on disk controllers for an OEM company.
It takes around 3 seconds to copy the 87 MB file from one folder on my hard drive to another folder of the same hard drive in my computer (I said COPY, not MOVE).
When you do a copy from one folder on a hard disk to another folder on the same hard disk, the data isn't moved to the computer memory. The cache memory on the hard drive is used for the transfer. Also, because the database files are managed by the SQL server rather than by the ACT! program, I don't know if the database files would be retained in memory or not.
Typical SATA drive gives you reading speeds somewhere between 60 - 80 Megabytes per second. That slow 4200 RPM drive gives us perhaps 20 - 30 Megabytes per second. Since the file is below 100 MB of size and Windows does the drive caching anyway, you can see how much sense the hard drive RPM suggestion makes. Not much.
Drive manufacturers love to quote transfer speeds and reading speed that can't be realized in the real world. While the read speed is accurate once the data is found the key is, once the data is found. As I'm sure you know the hard disk is organized in a series of concentric tracks. Also that finding the data involves going to the directory, reading the file information from the directory and then moving to the track (or tracks) where the data is stored. Because the directory is stored in track(s) other than the tracks where the actual data is stored, this means that to retrieve any single file requires a head move to the directory, read the directory, a head move to the data track and finally reading the data. Assuming the head move speed is the same, this is where the rotational speed of the hard drive comes in. Whenever you move to a new track on the hard drive, you encounter a thing called track latency. This happens because the data you want may be the first thing read after arriving at the track or the data you want may have just passed the read head and you need to wait a full revolution of the hard drive before being able to read the data. Because where the data is relative to the read head when the data read is attempted averages out over time, the disk latency will be the length of time it takes the disk to make half a rotation. For a 4200 RPM drive, the latency is 28.5 Milliseconds while the latency for a 7200 RPM drive is 16.6 Milliseconds. Given that all the data for a file typically isn't stored in a single track and may be scattered all over the disk (that's why we do defrags), the track latency makes the big difference in why a faster RPM hard drive will significantly improve the performance of the ACT! program. Remember, we are only talking about the data, if the swap file needs to be used, the situation gets even worse.
03-19-2009 07:20 AM
04-14-2009 05:30 PM
Guess what? Only minor improvements. It still can take 20 seconds just to clear an activity! And the other people on the program, with slightly older computers, hate it because it’s so slow. Fortunately I kept the 6.0 installed but unfortunately most everyone still uses it. I just don’t understand how ACT 6.0 could have been turned into ACT 11 and be so cumbersome and slow! I have asked a lot of people I know who use ACT if they have upgraded. So far, I'm the only idiot. They said to let them knwo when Sage came out with a decent upgrade. So, when might that be???