On Apr 26, 2017, at 5:12 PM, Douglas von Roeder via 4D_Tech <[email protected]> wrote:
> There are many, repetitive method calls. For example, each time the code > converts a byte range to a longint, it calls a function that returns the > byte order. As much as I never met a subroutine I didn't like, perhaps the > sheer number of them is impacting performance. As I mentioned, this shouldn’t matter if the code runs compiled. It will definitely make a difference interpreted. If you’re running compiled, it’s likely the speed issue is related to running 4D on a spinning hard drive. An SSD covers up a multitude of sins, and is cheap enough that now there is no sensible reason to not use one. An 128GB SSD, big enough for most normal 4D databases, probably costs less than an hour of your time, and will likely fix not only this problem, but others as well. For example, a process which deletes a bunch of data from a 4GB datafile so it could be used in the standalone version used by field reps used to take 45 minutes on a MacBookPro with 7200rpm drive. After installing an SSD, that process was about 5 minutes. On a newer MBP with PCIe SSD, it takes 90 seconds. FWIW, I wrote a few methods to work with Cannon’s OBJ module to pack selections of records for multiple tables to a C_OBJECT along with their table specifications, and unpack into the same fields (by number, with type conversion if necessary). It doesn’t follow relations or handle subtables. For unpacking you get a count of records for a table and unpack individually by index. Very few method calls, runs fast both interpreted and compiled. Maybe I’ll push that up to my Github account tonight. Jim Crate ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
