Question: This is the error am getting in work flow log:

> 
> ERROR 7/15/2020 3:00:19 PM node01\_DESKTOP-CK55616 7080 LM\_36320 Session task instance [s\_m\_Importing\_XML1]: Execution failed.
> 
> 
> 

I cannot open the session log.. even session fails means also we can open the session log, but now I can't able to open the session log.

session log error:

> 
> An internal exception occurred with [LGS\_10052]
> 
> 
> 

help me out!!

Answer: 
~~I see nothing particularly inefficient about your linked-list code, but~~ there are several reasons why a linked list approach in general might not be ideal performance-wise. Chief among those are

1. Dynamic memory allocation is fairly expensive on a per-call basis. With a linked list, the number of allocations performed by your code scales linearly with the problem size.
2. A linked list involves maintaining metadata, which takes up more memory and therefor reduces locality for accessing the data.
3. Per-node (or per-node-group) allocation is likely to inherently reduce data locality, as different allocated blocks are not certain to be adjacent to each other.

If you have a good, not-too-outrageous upper bound on the amount of memory you will need -- as it sounds like you do -- then I would strongly consider allocating the maximum you will need as a single chunk (just one `malloc()` call instead of many), using it as an array, and, optionally, shrinking the allocation with `realloc()` once you know how much you really needed.

Saving hundreds or thousands of `malloc()` calls is a sure win, though it's unclear how much of one. Likewise, having direct access to the data, with improved locality of access, is a sure win (of similarly uncertain magnitude). Also, even if you don't shrink the allocation at the end, you may well find out that you use less memory that way.

**HOWEVER**, as with any performance problem, you should *test* with a profiler to determine what parts of the program are taking the most time. Compilers are pretty good at producing fast code, and humans are pretty bad at identifying bottlenecks by code inspection. Do not risk spending hours or days making improvements to areas that don't really matter performance-wise. Find out first what parts you need to improve, then work on those.

**Update:**

On second look, I *do* see something *dreadfully* inefficient about your linked-list code: each time you add a node, you traverse the whole list so as to add it at the end. This makes building the list scale as O(n2). My comments about linked list usage in general notwithstanding, you could eliminate all that by either

1. adding new elements at the head instead of at the tail, or
2. maintaining a pointer to the tail of each list, so as to be able to add to the end without traversing the list.

Similar applies to function `lastNodeDeletion()`. Traversing the whole list to find the last node gets costly as the the list gets long. It's not clear to me how many times your program ends up doing that, but if that turns out to be slowing you down (see previous comments about profiling), then you could consider not only tracking the list tail, but additionally making it a doubly-linked list, so as to be able to delete from the end without traversing the list. (But note that "deleting" from the and of an array just means updating your count of how many elements are in use, which takes constant time for deleting a tail of any length.) Alternatively, if by adding at the head of the list you can also change your requirement to deleting from the head, then that also would eliminate the need to traverse the whole list to perform deletions.
> 
> *It worked well for small examples. But when an array with 0.5 million values is passed as input to this function, the performance decreased drastically.*
> 
> 
> 

That makes sense, [memory allocation is an expensive process](https://en.wikipedia.org/wiki/Memory_management#DYNAMIC), it certainly affects the performance of a program, that becomes apparent as you use it more often, i.e. in an extensive loop.

> 
> *Is there any alternative solution for the above problem or is there any other modification that needs to done to improve performance?*
> 
> 
> 

If you want to use heap memory there is no faster way, you must use memory allocation, I don't see how you would significantly improve the performance while still using memory allocation, though you could somewhat improve on it by allocating larger blocks at a time thus avoiding allocating in every iteration, or even allocating all the needed memory in one go if you are aware of the total needed size.

Using stack memory is definitely faster and would be a good alternative, but in your case, since you are working with large amounts of data, that may not be possible, [the stack size is very limited](https://stackoverflow.com/q/1825964/6865932).

This said, the best way to assert the inefficiencies of your program is to [test it yourself](https://stackoverflow.com/q/5248915/6865932), surely memory management is not the only thing you can optimize. You can also use tools that allow you to profile the execution time of the program, for instance, in Linux systems, [Callgrind](https://www.valgrind.org/info/tools.html).