portal entry

Thanks for digging into this, John (aka Yorik). But I do think you've missed an opportunity. As mentioned in the doc quote, the feature is about concurrent access to a given array in multiple threads at the same time. Your speed tests are all taking place in a single template, thus a single thread. As such, your testing more the implication of using the feature with leveraging its benefit. There's some value to that, sure (to assess the cost, in single-thread processing) But there would seem far more value in showing multiple requests (or cfthread threads) running the code concurrently. And especially editing content in the array, rather than just reading it (though timing of reading alone would be valuable, too). Finally, as for your observations of speed differences between cf2016 and cf2018, it would be valuable to know if these were on the same machine,  and with identical admin settings (and identical application cfc/cfm processing--best if they both have a blank application file to ensure no unexpected inheritance of another). All good fodder for another post, if it interests you. Hope that's helpful. And I'm sure I speak for most in saying we appreciate the many posts you make.

Comment by Charlie Arehart

Hi <a href="https://coldfusion.adobe.com/profile/Charlie Arehart">Charlie Arehart</a>, It was my intention to dig into running it via runAsync and to see how race conditions could occur, but when I saw that the difference in speed wasn't going to be like day-and-night then I went off into a tangent of trying 2016 vs 2018 and sorting etc to see what that produced. I'll see if I can get around to writing a follow up - and I write nowhere near as much as you do! 

Comment by aliaspooryorik

Thanks for that, John. As for trying things out with the runasync feature (new in 2018), while that would be interesting to many, I would propose that since the feature was added in 2016, you may do well to stick with testing things via cfthread (or just some means of firing off multiple requests). That way, those NOT on 2018 could see the benefit--and that could benefit those even on CF11 and earlier, who might then try out your code to see how things perform for them, with the old array type, to compare to your tests in CF2016 or 2018. Of course, there can be other explanations for differences between one CF version and another. Indeed, I had asked if you might clarify for us if there were any that might explain the differences you saw between 2016 and 2018. I will assume you meant that you would try to address that in any follow-up. And as for how you "write nowhere near as much as" I do, I think that was a compliment. :-) If you mean I post a lot of blog entries or answers, sure. But some think I wrote "too much" in those, and in replies like this. I write like I would speak...which may not be any better an explanation! :-) Cheers.

Comment by Charlie Arehart

Hi Charlie, All valid points. The tests between ACF2016 and ACF2018 aren't on the same setup - I wasn't trying to compare speed betweenACF2016 and ACF2018, rather the speed of synchronised vs unsynchronised arrays on the same engine. I was trying to find a good use case where an unsynchronised array was a no-brainer, but I just can't get a big improvement whatever I try! I have tests which use cfthread that show how you can end up with missing array elements (so reasons NOT to use unsynchronised array) but my tests don't show a noticeable improvement in performance, so not quite sure what to blog as my goal of showing where unsynchronised arrays are beneficial just isn't revealing itself to me! At the moment I can't really see where I'd use an unsynchronised array, unless I wanted to save a few milliseconds. It was meant as compliment Charlie - your posts are a valuable resource to the CF community!

Comment by aliaspooryorik

Thanks for that, especially for the kind regards in your last paragraph. As for your having trouble showing the performance difference (in a given version) between the two types, well, again that was really the main point of my first comment. I think you'd see the impact more clearly (if there is one) by running tests that modify and/or access such arrays (or each type) in requests running in multiple concurrent threads. As the docs read, that's when the performance hit is noticeable: "The second thread has to wait until the first thread completes its job, resulting in significant performance deterioration." So you want to show it being used in that way. Perhaps you could also show how then the the unsynched array would suffer reliability problems (due to race conditions) . But I know your main focus was to find the speed difference: I think you'll only notice it when using the two approaches in more multi-threaded way. (And I realize that you may wonder still, why should I use an async one then, if I know I can't use it in a multithreaded sitaution. But the question will be "how does it perform when multiple threads are indeed only reading the shared array?" Perhaps think of it more as a read-only flag to speed up such processing, when using multiple threads.) That said, I have not used it myself, so I can't say any more than these thoughts so far. I will add, though, that since the concept (of synch'ed/unsync'ed arrays) is in fact a generic one, you could look to other resources that discuss it, for more insights. Here's one: https://www.geeksforgeeks.org/synchronization-arraylist-java/ And it says that by default Java's equivalent ARE unsynched. There's no date on that article to see when it was written and what JVM it refers to, but we could reasonably assume that had not changed. Perhaps it's that Adobe inherited from Macromedia (and even Allaire) CF's default to have them be synched, and they wanted to offer this means to unsynch them, for those occasions where it would speed things up. I know it's the "where" that you are seeking. :-) Finally, just to be clear, when your last point addressed the speed differences reported between CF2016 and 2018, I'll just say that it wasn't stated in the original post that they were on different machines, right? So we couldn't have known. :-) And while you may not have intended for your observed differences between them to be used as a comparison BETWEEN them, it's only natural that folks would infer that, right? :-) I suppose now that you have clarified those things, that may suffice. But I would propose that editing the post to make them more clear could help many readers. Your call. I know it's an annoying characteristic of this portal that if we (as writers) edit our posts, the post is then taken OFFLINE while awaiting moderation. That's just shocking to me--I would understand if it left the previous version online while the new one awaited moderation--and I have complained of it many times to Adobe.

Comment by Charlie Arehart

Yes, having the post taken offline is very annoying. I've also just discovered you have to login just to *view* these replies - what the heck is all that about! I think I'll post an update in the comments. I've tested read-only and no difference. As I understand it then it's the mutation that causes the issues. Synchronised needs to lock it for updates, which adds a bit of overhead, but it seems to minimal at best. I'll keep digging and hopefully the fog will clear and I'll uncover something worth posting!

Comment by aliaspooryorik

<strong>UPDATE:</strong> I'll clarify that I'm not testing ACF2018 and ACF2016 on the exact same setup so do not look at the speed differences between the two engine versions. I posted the timings to show the difference in speed between Synchronished and Unsynchronised arrays on the same version of ColdFusion.

Comment by aliaspooryorik

Thx, on all points.

Comment by Charlie Arehart