|
Hi Suren,
The system is extremely efficient at using disk space for memory,
especially when compared to something like Windows (which is not so
efficient at that.) But, of course, using less memory will always be
more efficient than using large amounts of memory. Unless you're talking
about a lot of simultaneous jobs, though, I don't think you'd notice the
performance difference. By contrast, parsing it twice (once to get the
array sizes, and again to actually load the array) may make a big
difference if these are indeed large documents.
Are you saying that your RPG array of data structures would be larger
than the 16mb maximum? If so, using dynamic memory wouldn't solve that
problem. Instead, you'd want to use the %HANDLER BIF with DATA-INTO,
which is both easier to code and would use less memory.
-SK
On 6/20/19 4:43 PM, Suren K wrote:
Hi Scott,JSON.
My requirement is to use minimum 10 arrays in a request to parse the
So each array if i am defining it as 9999 elements, then i am thinkingthe
program will use additional memory space. Also, if we are getting some 50affect
transactions at the same time in parallel for this similar kind (Each
Request which contains more than 10 arrays) of parsing then it might
the performance correct?allocation.
Regards,
Surender K
On Wed, Jun 19, 2019 at 4:04 PM Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx
wrote:
Suren,
Why not always define the array with a 9999 size? That seems much
simpler and more robust. What are you gaining by declaring it to a
pointer and only allocating part of it?
If you did want to do it with a dynamic allocation, you could do it by
calling YAJL's subprocedures to parse the document (i.e. don't use
DATA-INTO, just call YAJL's routines). This could give you the size,
and then you could parse it a second time with DATA-INTO after you knew
the size and have allocated the data. But this would be more
complicated, and parsing it twice (no matter how you do it) will take
longer than parsing it once. So, I would simply always declare the
array with the full 9999, I would not bother with the dynamic
the
-SK
On 6/19/2019 2:36 PM, Suren K wrote:
Hi Everyone,JSON
I am using Scott's YAJL Parser using DATA-INTO opcode for Parsing the
Document. I need one clarification.
Currently i am using the JSON Document which contains an array which we
cannot limit the number of elements. So i need to define an array data
structure with minimum 9999 elements by assuming the number of elements
will not exceeds 9999.
Instead of doing this, i am planning to use pointer based array data
structure. Once i identified the number of elements by using the option
"Countprefix", i can allocate the data structure based on the number of
elements and then use the data structure in DATA-INTO to parse the full
data.
But i could see the "countprefix" option is working only when we pass
--array Data structure together with the countprefix variable in the--
DATA-INTO Opcode.
Any suggestions to how to identify the number of elements first before
parsing the Entire Array?
Regards,
Surender K
+1 7022091188
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
Scott Klement
http://www.scottklement.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.