Memory-based caches are great and it is frustrating to have to resort to building them scratch. How much speed difference will it make? I have no idea, and it depends on what you're caching, where you're caching & how much it costs to load the cache. I was recently working with PHP (on its own, not via 4D) for a spell and got a bit frustrated at the CGI-like processing model:
* Invoke PHP script. * It runs with a blank slate. * Set things up. * Go die now. This approach makes sense, given PHP's roots, and it has some advantages...or can be seen to have advantages. Anyway, I have some static lookup arrays that I would like to cache. They let me translated user-friendly labels into stable record IDs for various callbacks. So, imagine a pair of arrays and a simple lookup on a unique string that returns a unique number. Options: 1) Cache them in a disk file and reload from disk when the PHP process launches. 2) Build the values right into an array in the script so that it loads at startup. 3) Make a database connection and fetch the necessary data. 4) Use an in-memory cache, like Memcached. I tried testing out a bunch of solutions that were workable in my case and was surprised to find that #2 was very competitive. I pre-build the array declarations into the script and then they're right there. (I used 4D to build the script.) #1 brings hassles and going to the file system is typically "slow". Setting up a DB connection is, likewise, a bit slow and expensive for a quick lookup. I didn't try Memcached, but would if I had a good production reason for it. The moral of the story is that performance depends on context and the only way to find out what something costs is to measure it. In your case, it may be that reloading the data isn't as expensive as you fear. Or it might be bad, there's no way of knowing a priori. Note: The PHP discussion above wasn't just me wandering around and not getting to the point. I think ;-) Going back to the #2 solution, I've got a PHP script that does some work - that's all written as normal PHP. Then I've got some lookup values that belong in the script. They're static once the script is built, but they need to be injected from 4D. So there's a template: * Load template. * Inject dynamic data from 4D into the PHP script as array definitions. * Copy script to target folder. Now it's stable until rebuilt. Not every situation allows for such an approach, but we're already talking about ones that do. The very same idea is totally practical in 4D: * Define a method template or use a special comment marker in the method you want to inject static values into. * During your build cycle, include a step to update whatever methods you need with METHOD SET CODE. * Build and deploy. I use a screen to do a bunch of stuff before and after building and it would be easy to add 'inject static assignments' as a step. Why not? METHOD SET CODE is great, for those that haven't used it. So, your binding is right before compile time, but definitely before runtime. Earlier binding = good news, for the most part. ********************************************************************** 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] **********************************************************************
