Re^2: Thread::Queue memory issue with nested maps but not foreach loops...

Everything in your post makes sense to me; however, I have a single threaded version of the program that uses the same amount of memory using both the nested maps and the foreach loop. Also, aren't newer versions of perl optimized such that when map is used in a void context, the extra work that differentiates it from foreach and from for optimized away? (Source: http://www.perlmonks.org/index.pl?node_id=296742)

The threaded version and the single threaded version are basically identical except instead of loading a queue, I call &doWork on the string. If the Thread::Queue was not part of the problem, shouldn't nested map use more memory than the nested foreach loops? From my testing, the outrageous use of memory only occurs when I am using Threads and Thread::Queue, otherwise the two perform similarly.

Thankyou

Comment on Re^2: Thread::Queue memory issue with nested maps but not foreach loops...

Replies are listed 'Best First'.
Re^3: Thread::Queue memory issue with nested maps but not foreach loops... by BrowserUk (Patriarch) on Mar 03, 2012 at 05:20 UTC
Also, aren't newer versions of perl optimized such that when map is used in a void context, the extra work that differentiates it from foreach and from for optimized away? (Source: http://www.perlmonks.org/index.pl?node_id=296742) The optimisation relating to map in a void context is that map doesn't build the return list (what would be returned from the map) when it detects it is called in a void context. It doesn't (I think "can't", but I not sure of that), stop the input list being built. From my testing, the outrageous use of memory only occurs when I am using Threads and Thread::Queue, otherwise the two perform similarly. Post -- or send me via the mail ID on my home page -- the real code. Then we'll see. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]
Re^4: Thread::Queue memory issue with nested maps but not foreach loops... by ikegami (Patriarch) on Mar 03, 2012 at 08:40 UTC
It doesn't (I think "can't", but I not sure of that), stop the input list being built. It could be done. The opcode checker can transform the opcode tree when it detects a pattern that can be optimised. It can even be implemented in a module outside of core.	[reply]
Re^5: Thread::Queue memory issue with nested maps but not foreach loops... by BrowserUk (Patriarch) on Mar 03, 2012 at 09:41 UTC
If it is possible, I'm really surprised it hasn't been done already. Seems such an obvious thing if there are no technical limitations preventing it. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]