Monkey Blog Stuff
Monkey Archive Forums/Monkey Tutorials/Monkey Blog Stuff
| ||
| I'm not sure if this really fits with what simonh wanted from this forum, but it seems to be a good match for what I'm doing and it's pretty quiet in here. Feel free to move or delete this if you wish. Anyway, I'm starting to write some blog posts about Monkey. Tips, lessons learned, that sort of thing. They might be of interest to people here (and if not then I've no idea who else would care!) so I thought I'd start dropping links in here. So, here's one on how performance varies across targets: http://pointlessdiversions.blogspot.co.nz/2012/03/monkey-tip-relative-target-performance.html Feel free to comment here or on the blog if you think I'm getting something wrong. Or right. |
| ||
| Good stuff, muddy! Keep it up! |
| ||
| Thanks. Coincidentally, I've just put up a new post about box classes: http://pointlessdiversions.blogspot.co.nz/2012/03/monkey-tip-be-careful-around-unboxing.html |
| ||
| Thanks for posting. Thorough and well written. |
| ||
| These are great to read muddy shoes, keep it up :) Re: monkey-tips-default-types-and-implicit.html My write up would just be: Just use "Strict" mode - The End ;) Re: 1d-vs-2d-arrays-performance-reality.html It would be good to see your testing code. |
| ||
| My write up would just be: Just use "Strict" mode - The End ;) Well that is the take home. The thing is that if you don't understand the issues with not using Strict it just seems like it's an annoyance. It would be good to see your testing code. I'll sort something out with attaching code to relevant posts at some point. Most of these tests aren't written as code for public consumption though. Tidying things up and making them into neat packages for posting is an additional time burden. If someone created a test that showed something very different I'd be happy to revisit the code to see what's up, of course. I'll probably write a post about performance testing for Monkey in general and post some template code for that. |
| ||
| I'm with therevills -- these are really good reads, thanks. |
| ||
| This post isn't really about Monkey, but it's about something written in Monkey and there's code linked so it might be of interest: http://pointlessdiversions.blogspot.co.nz/2012/05/tetris-in-how-long.html |
| ||
| good read. And of course, challenge accepted!! Will have a bash at Tetris later after I've sorted out a few errands in town. I'll let you know how I fair... 2 hr is going to be a challenge, I tend to slip off into dream land for at least 15 mins every hour and spend far too long playing, err i mean 'testing' my code! |
| ||
| The last post is fun! Thanks for your insights :) |
| ||
| Got around to writing something again: http://pointlessdiversions.blogspot.co.nz/2012/06/monkeys-garbage-collection-on-ios.html Just a cautionary note about garbage collection behaviour on iOS. |
| ||
| Another great read Muddy :) On the topic of GC, you need to be careful with Android too... try not to create any new objects during your game and preallocate all your game objects beforehand (note: using the default Monkey List when you iterate over it you will create a new object!) |
| ||
| Sure, GC can be an issue on any platform that implements it. The problem with iOS is that the default behaviour will be made worse by taking your suggestion of pre-allocating. Further, even if you have zero allocations the iOS GC will probably still be doing pretty much the same amount of work as marking the objects generally takes much longer than sweeping. Zero allocation is a nice thing to have but not always practical to achieve. If you're down to worrying about list iterators then you'd have to be almost done though as they're both small and unlikely to be numerous. Most GCs don't trigger until a certain amount of allocation has taken place and a few list iterators per frame certainly aren't at the top of my list of trouble makers. |
| ||
| On how the Android GC works, every time you create a "new" object you are saying "Hey GC, go for collect for me and kill me game!". With iOS I never had an issue with the GC, but all I did was a simple card game :D |
| ||
| Excellent. Thorough and well written, as usual. Thanks for taking the time. |
| ||
| On how the Android GC works, every time you create a "new" object you are saying "Hey GC, go for collect for me and kill me game!". Any given allocation might result in a collection event but GCs aren't generally written so naively that they try to collect as soon as you allocate an object. There's obviously no benefit in attempting to recover memory based on the demand of a single allocation so they don't. Here's the Android GC activity using a version of the test from my post that allocates and releases 20,000 objects at a time: Yes, if you've got some internal method call that uses a list iterator and gets called dozens or hundreds of times a frame then it'll be adding to your GC burden. On the other hand I think it's a little misleading/over-simplified to talk about using them at all as a big no-no or that any object allocation will result in the GC monster stomping through your living room. Obviously, if you want absolutely no GC at all guaranteed over long play sessions then you're going to have to remove all allocations. Unfortunately the nature of mobile OSes means that other processes will come along and mess up your timing anyway so expending a lot of effort removing all allocations might not gain you much in terms of user experience on Android (at least on 2.3+ where the GC is pretty fast but then anything less is rapidly becoming legacy). If you're targeting XBox or PS Vita then there's probably more reason to put the time into avoiding any collection costs. |
| ||
| Having said that I had a bit of a think and decided there's no reason not to have the best of both worlds. I've altered the monkey parser to call a Discard method on the ObjectEnumerator after it creates a While loop for the Eachin. A simple cache array for enumerators in the collection and you have no GC issues and no need to lose the syntactic sugar. |
| ||
| Time flies... a year since I added to this? Wow. Anyway. A recent Twitter conversation with Raph and head-desk debugging experience led me to revisit the topic of autoboxing and add a further warning: http://pointlessdiversions.blogspot.co.nz/2013/07/boxes-sneaky-buggers.html |
| ||
| Aha, now I can connect you to the Twitter handle! :) |
| ||
| nice blog post. |
   |