On Oct 22, 2019, at 11:42 AM, Chip Scheide via 4D_Tech <[email protected]> wrote:
> I am just getting started playing/using objects. > > I wrote some routines to determine if a particular property/value > exists either in an object, or in an object which is part of an object > array. > > Given: > - the object is complex, i.e. has 1 or more sub-objects included and/or > an object array included > - the only interest is does the property/value pair exist (true/false) > > It occurred to me last night, that this processes maybe significantly > faster, and less complicated, by simply converting the complex object > to text (JSON Stringify) and then use POSITION to locate the > property/value pair. > > Has anyone looked at this? is using JSON faster? slower? no difference? > or 'it depends'? > other comments? It always depends. For small numbers of small objects, you'd spend more time figuring out what is faster than you’d ever save using the faster mechanism. For an object with a large object array (I.e. > a few hundred objects in the array, each with 10+ properties, some of which are objects with 5+ properties) it takes a ridiculously long time to get that object array from the object value into an object array you can access, so it might indeed be faster to JSON Stringify the object containing the object array. However, in this case, simply using Position to locate an attribute name is kind of pointless, since you’ll have to parse the entire json text to know which element of the array you found the property in, or to find the property in a specific element of the array. Keep in mind any code you write to deal with object arrays will be obsolete when you update to V17 and can use collections. V17 and dot notation also obsoletes some of the code you’ll write to deal with multi-level objects and other convenience code. If your V17 upgrade window is less than a couple years out, I’d recommend not even using objects except for cases where the functionality built into v15 makes using an object easier than using the other primitive types available in 4D. Realistically, the cost to upgrade to v17 is probably lower than the cost to build the missing functionality again (it’s already been built by most other 4D developers who started using objects in v15, and that’s why most are saying just use v17). I get that in a salary position, writing a bunch of code that will soon be obsolete (again) can be easier than pushing for purchase approval for v17. However, v15 was not terribly stable for us when we moved from v13. Later versions of V16 were more stable, but many users still crashed often when interacting with the file system (open/save dialogs). V16 also had problems with user disconnections, ghost users, and sometimes some server-side processes stopped running, requiring a restart of 4D Server. So far with 64-bit v17 client and server (all macOS environment), stability has improved in all these areas. So if stability and reliability are important, you should push updating to v17. Jim Crate ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
