I would love for this to be a fixable problem. I just upgraded from Pan 6 and am finding X so slow that I cannot work with it. Granted, it’s a large file, but 6 handled it with no problem.
I have a MacBook Pro (Retina, 13-inch) with a 3.1 GHz Intel Core i7 and 16 GB 1867 MHz DDR3.
Here’s a comparison of times for the same file. 1,270,000 records (205 MB)
This was on a fresh restart with nothing else really running.
The commands below were run in sequence.
Open file: Pan 6 - 3 seconds Pan X - 2:47 minutes
Propagate field: Pan 6 - 3 seconds Pan X - 46 seconds
Group up: Pan 6 - 8 seconds Pan X - 12 seconds
Analyze Maximum: Pan 6 - 4 seconds Pan X - 4 minutes
I have 30 fields I need to find the “maximum” of once they are propagated and grouped up, so 4 minutes for each column is just not acceptable.
Is it just me or is Pan X really this SLOW??? Is there something I can do to speed it up? I just signed up for 60 months because Pan 6 is so good, so I would really like this to work.
It might speed up Analyze Maximum if you preceded it by collapsing your database to the level of your Group. It shouldn’t change the result as each value in the database will show up once in that Summary level, but might not have to look at the redundant multiple copies in each Group.
Panorama X is certainly slower than Panorama 6.0 for most very large databases - I’ve experienced factors of 10 or 20 times the run time for a database with 50 fields and 4 million records. I also kept running out of memory, even with 16GB of RAM. My solution there was to write a procedure to subdivide the original file into say 20 sub-files, process each one individually and then glue them back together. I can send you sample code for this if you want.
As a starting point though, you might put this at the beginning of your procedure:
clipboard = ""
let Tim = now()
… then intersperse your procedure with statements like:
clipboard = clipboard() +cr()+ str(now()-Tim)
Tim = now()
At the end, look at the clipboard and see how many seconds each sector has taken - you will probably find one sector that’s taking most of the time and you can focus on how to make it more efficient.
One thing that can really help with speed when using the datasheet is to bracket your code with noshow and endnowshow.
noshow
// do all your data processing here
showpage
endnoshow
An area that is contributing to the longer times is due to Panorama X doing all the text processing using UTF8 (Unicode) instead of the much simpler outdated Mac Roman as used in Panorama 6. The change to Unicode is obviously desirable for modern OS comparability and the ability to use extended character sets and various foreign languages. Another thing is that I don’t believe Panorama X has been completely optimized yet and this may (or may not) help speed things up down the line.
Thank you all for your responses. I could try collapsing the groups, but I am constantly opening text files imported from other programs, and just opening this file alone took almost three minutes. That’s before any procedures, any grouping, anything… Michael, your idea is intriguing, but I don’t have one main file that I work with. I might open six to ten of these very large files daily, do some very limited manipulation (propagate, group, max, then delete detail and export), so I breaking up the files into 20 or so pieces and manipulating each one would actually increase the time and effort. Also, as powerful as code can be, I don’t really want to have to write code since the simple commands have always been sufficient.
I appreciate all your comments, but I remain very frustrated. My only solution might end up being having to partition my Mac and continue to run Pan 6 on an older system when the END finally arrives. The price we pay for progress indeed…
Panorama X is somewhat slower than Panorama 6, this is mostly because Panorama X uses Unicode text, which is MUCH more complex to process than the 8-bit text that Panorama 6 use. I know a few of you will say that you’d rather have faster 8-bit text, but that really isn’t an option for an app that uses modern macOS APIs, since all of those APIs require Unicode text, and ALL other applications on the Mac use Unicode.
However, I am surprised by the very slow times you are reporting. I don’t have a file as large as your, but I do conveniently have the FAA Aircraft Registration file which we use a a demo file and is available in the database exchange. It is 313,000 records, about 80 megabytes, and on the quite slow 12” MacBook I am using tonight it opens in about 2 seconds, does a group in about 5 seconds, does a propagate in 4 seconds, and performs a maximum in 2 seconds, Since your database is 3 times as large I would expect these operations to take place in 5 to 15 seconds. I do not know why you are seeing times the are so much slower.
I know of one customer that has been able to work with a database with 32 million records. It’s of course not super speedy, but when they tried to import the same data into Excel it just crashed. And the database did open in around a dozen seconds (opening a file should not take much longer for larger files, it does not scan all the records when it opens).
The word “forever” is coming from Michael, it is not a promise from ProVUE. At a minimum, the serial number registration server may not run forever. We don’t have any immediate plans to discontinue it, but it is itself based on Panorama 6 so I can see where that might be difficult to keep working on a server at some point in the future. Any existing computers would continue to run, but you would not be able to activate Panorama 6 on a new computer any more.
