I have a situation in Java Collection and i am not able to figure a good solution. I am scared about the performance and memory that wil be used
I have 5 List objects with thousands and thousands of records in it. The List is populated by a database query using jdbcTemplate which return like 200,000 records
Each record is identified by POLICY_ID. They may be List with multiple records for a POLICY_ID
I want to extract each POLICY_ID from all the 5 List and make a single List object for each POLICY_ID and for each List and pass it to a print job which will print the data for a POLICY_ID
Let say we have POLICY_ID = 15432
List1 has one record for 15432
List2 has one record for 15432
List3 has one record for 15432
List4 has three record for 15432
List5 has three record for 15432
From the 200,000 records in List1 i want to generate a seperate list with 1 record for policy id 15432 and let name is Listperpolicy
after this logic we have
If anyone can guide me to create a faster logic for the above scenario it would be very helfpul
call print job ( Listperpolicy1, Listperpolicy2, Listperpolicy3, Listperpolicy4, Listperpolicy5)
Please let me know
Thanks a Lottttttttt
Pinned topic Faster code with List Collection object
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2007-01-24T13:18:44Z at 2007-01-24T13:18:44Z by SystemAdmin
SystemAdmin 110000D4XK210 Posts
Re: Faster code with List Collection object2007-01-24T13:18:44ZThis is the accepted answer. This is the accepted answer.If the printing code doesn't do anything more than iterate through the List (no mutating of existing List items, no adding new ones) then I think you could just write a small adapter class that implements List and fronts it with your 5 big Lists.
e.g. iterating across the new adapter is done by iterating across the 5 big Lists consecutively, get operation indices are calculated using the 5 big Lists' size functions, etc.
This involves writing and unit testing a big of code, but the only runtime cost you'll pay is the memory overhead of a small adapter class and the invocation latency of going through 1 additional API layer. Both are smalled compared to duplicating references to hundreds of thousands of objects.