On Wed, Apr 26, 2017 at 10:37 PM, David Adams via 4D_Tech < 4d_tech@lists.4d.com> wrote:
> Gotcha. I've got my main code base in V13 still and like it fine. > > I still feel behind on this thread...what turned out to be the source of > the slowdown? Packing? Unpacking? Transmission? Some combination or > interaction of the above? > My suspicion is that the bottlenecks are the decoding and the inability to Pause indexing. I'm not thinking that there's much I can do about the decoding. There are a lot of wrapper routines called as functions that do nothing but return the value of a 4D constant. Most of those can be eliminated by just using the 4D constant. But the resource cost of loading a method and getting the value of a constant is very low. And we're talking about updating 3.x records per second - not 3.x hundreds of records but a Lawrence-Welkian "a one anna two anna three" records per second. > I ask because there are alternatives at every > step. In arm-wavingly broad strokes: > > * Reducing the amount you need to transmit: Pays for itself quickly > (usually.) > * Reducing the amount you need to compare: Pays for itself quickly (or is > likely to.) > * Reducing the _number_ of transmissions: Can also be a big deal. > > On the last point, a non-4D example. Try downloading a couple of hundred > individual files over FTP. Ugh. Takes forever. Now try transmitting those > as a single archive. Fast. Any chance you could bundle what your remote > users need in a file *in advance* (or on demand, I guess) and then transmit > it as a download via a single call? You've got HTTP Get, as an example. > Then they can unpack it and process it locally, even if their connection is > closed. > No question about that. Performance tests of storage show that 4k blocks are brutally slow compared to 1 GB blocks. Nature of the beast. What we're hitting is not transmission time but time to encode/decode and commit.++ The server is updating 3.5± records per second with a good chip, lots of RAM, and an SSD. The folks in the field are doing the encoding on laptops and then they're bringing down records, decoding them, and committing them. The server can churn away for hours but this is a real pain for the folks on the laptops. "Sync early, sync often" is their watchword but there are some users who wait until they have thousands of changes so they have to be patient and wait until their computer finished processing. The phrases "patient" and "wait until the computer is finished processing" are not phrases that match "sales rep". Not even fuzzy match. > Again, not sure I'm clear on the story so I may be saying things that are > kind of irrelevant. Still, from what you say, this is one of those > situations where some big gains are totally possible. Those are getting > harder to find these days ;-) > Very true. On the other hand, "nothing is slow at 3 GHz". Oh, wait… > P.S. For loops are faster, as we all know ;-) > Two important things there - always use a longint for your index counter and set the text for a For loop to a really small font and then color it red. Works like a charm! ;-) -- Douglas von Roeder 949-336-2902 ********************************************************************** 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
