Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'index' routine shows severe performance decline in a loop #2593

Open
SqrtNegInf opened this issue Jan 9, 2019 · 6 comments

Comments

Projects
None yet
4 participants
@SqrtNegInf
Copy link

commented Jan 9, 2019

The Problem

Performance for 'index' routine in a loop grows increasingly worse as memory use grows without bounds:

index $_, 0 for 1 .. 10000

True of 'rindex' as well. Difference in valgrind output between good/bad versions for the above snippet:

999,200,592 bytes in 2,018 blocks are still reachable in loss record 2,181 of 2,181
   at 0x10000A261: malloc (vg_replace_malloc.c:302)
   by 0x10004CD16: MVM_fixed_size_alloc (in /Users/dhoekman/.rakudobrew/moar-66f8ee0fb/install/lib/libmoar.dylib)
   by 0x1000D1141: add_resolution_to_guard_set (in /Users/dhoekman/.rakudobrew/moar-66f8ee0fb/install/lib/libmoar.dylib)
   by 0x10003A048: remove_one_frame (in /Users/dhoekman/.rakudobrew/moar-66f8ee0fb/install/lib/libmoar.dylib)
   by 0x100039AC7: MVM_frame_try_return (in /Users/dhoekman/.rakudobrew/moar-66f8ee0fb/install/lib/libmoar.dylib)
   by 0x10001FB81: MVM_interp_run (in /Users/dhoekman/.rakudobrew/moar-66f8ee0fb/install/lib/libmoar.dylib)
   by 0x1001592B5: MVM_vm_run_file (in /Users/dhoekman/.rakudobrew/moar-66f8ee0fb/install/lib/libmoar.dylib)
   by 0x1000012B6: main (in /Users/dhoekman/.rakudobrew/moar-66f8ee0fb/install/bin/moar)

LEAK SUMMARY:
   definitely lost: 888 bytes in 2 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 242,192 bytes in 4,328 blocks
   still reachable: 1,058,103,527 bytes in 222,498 blocks
        suppressed: 22,284 bytes in 193 blocks

Environment

The problem began with commit 66f8ee0

This is Rakudo version 2018.12-64-gef565b2ba built on MoarVM version 2018.12-4-g1404d5168
implementing Perl 6.d.

@lizmat

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2019

FWIW, --profile does not show anything weird wrt to allocations or anything.

@lizmat

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2019

Also: seen the given code explode to 2+GB of memory usage in matter of seconds.

AlexDaniel added a commit that referenced this issue Jan 9, 2019

Tweak ISSUE_TEMPLATE
Make it even clearer that parts of the template can be
deleted. Inspired by a short yet amazing ticket #2593.
@jnthn

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

by 0x1000D1141: add_resolution_to_guard_set (in /Users/dhoekman/.rakudobrew/moar-66f8ee0fb/install/lib/libmoar.dylib)

That's the key line, and means we've triggered a problem most likely in the return type checking spesh plugin.

@SqrtNegInf

This comment has been minimized.

Copy link
Author

commented Jan 10, 2019

Tested this PR locally, and can confirm it clears up the problems I was seeing.

@AlexDaniel

This comment has been minimized.

Copy link
Member

commented Jan 10, 2019

I'll reopen with a hope that eventually we'll be testing things like this. It's actually relatively simple in this case given how fast the memory usage grows. Maybe make test should be monitoring memory usage of every test file, or something like that?

@AlexDaniel AlexDaniel reopened this Jan 10, 2019

@lizmat

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

I close the ticket because I couldn't see a way to test this reliably.

But generally a test for memory growth might make sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.