On Tue, May 26, 2009 at 12:47 AM, Robert Green rbgrn@gmail.com wrote:
That is SO MUCH more code than I ever wanted there but it's
ridiculously more efficient than it was before so I'm going to call it
good and move on.
It looks like a lot of your code comes from C code that had to run
On Mon, Jun 1, 2009 at 9:20 PM, Robert Green rbgrn@gmail.com wrote:
Dan, thanks for clearing that up.
Glad to be of service.
It's always nice to have *the* guy who wrote the VM
(emphasis mine) I definitely can't take all that credit, not being
surrounded[*] as I am by the *many* fine
David,
That's not my code - that was a package method ripped from
java.lang.Integer. I had to copy/post it because it's needed to make
write an int's String's char[] directly without instantiating
anything.
On Jun 2, 7:27 am, David Turner di...@android.com wrote:
On Tue, May 26, 2009 at 12:47
On Tue, Jun 2, 2009 at 11:27 PM, Robert Green rbgrn@gmail.com wrote:
David,
That's not my code - that was a package method ripped from
java.lang.Integer. I had to copy/post it because it's needed to make
write an int's String's char[] directly without instantiating
anything.
no
On Mon, May 25, 2009 at 1:34 PM, Mark Murphy mmur...@commonsware.com wrote:
2) What about local variable arrays? Do those go in the heap (short
lived, GC) or on the stack?
The array is on the stack. If the array is a primitive array (int[]),
that covers everything. If the array is of
Dan, thanks for clearing that up. It's always nice to have the guy
who wrote the VM step in and steer us lowly developers in the right
direction :)
I do have a logical question following your example, though:
If a blort can snort,
and a snort is a fort,
are all blorts forts?
On Jun 1, 7:34
Have you tried using hprof/jhat ?
See
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/heap-profiling.html;hb=HEAD
On Mon, May 25, 2009 at 1:02 PM, Robert Green rbgrn@gmail.com wrote:
For the past 2 months of development, I've followed the android
performance
Yes, I've done an HPROF and have it open in Eclipse Memory Analyzer
but it doesn't appear to be telling me what is being GCed. It looks
like it's the result post-GC and is more suitable for memory usage and
leak detection. I could be missing something, though. Anyone?
On May 25, 3:08 pm,
The easiest way to find out what is being allocated is to use DDMS'
allocations tracker. Launch DDMS (the *stand alone* version, not the
one in Eclipse), swtich to the Allocation Track tab, select your
process, hit Start tracking, play with your app, then hit Get
allocations. Each allocation will
Robert Green wrote:
1) Are local variables ever affected by GC if they never call new,
either explicitly or implicitly?
-- I'm asking if I have a field that is private ArrayListDog
dogList; and in my method, I say ArrayListDog dogList =
this.dogList; - that doesn't have any impact on GC,
Awesome! Those are the assumptions I've been working under for months
and I'm so happy that I wasn't way off on one of them!
I found that the standalone DDMS has an allocation tracker which is
exactly the tool I needed. I immediately found my problem. Two
problems:
1) I keep a running score
1) I keep a running score on screen. The StringBuffer I'm using to
build this is causing all types of char[] and String allocations. I'm
not sure what I can do about that.
You can reuse a StringBuffer by deleting its content, we do that in a
bunch of places in Android's source code. You
Romain Guy wrote:
You can also avoid calling
toString() on it or passing it to methods that treat it as a String.
Calling toString() creates a copy of the buffer, which you certainly
don't want.
Yeah, I'm pretty bad about that one. I keep forgetting
StringBuffer/StringBuilder implement
I said StringBuffer but I meant Implied StringBuffer, you know:
canvas.drawText(score + POINTS_LABEL, x, y, paint);
I'm not sure how I can make that more efficient since drawText takes
either a String or a CharacterSequence and all I can think of doing is
hanging on to a char[] that is
Robert Green wrote:
I said StringBuffer but I meant Implied StringBuffer, you know:
canvas.drawText(score + POINTS_LABEL, x, y, paint);
Why redraw POINTS_LABEL every time? Can't you rework your scoreboard to
only draw that once?
--
Mark Murphy (a Commons Guy)
http://commonsware.com |
It's a surface view so the whole scene must be rendered every frame.
I could put it on the background I suppose but it's simple enough to
just redraw the text.
On May 25, 4:10 pm, Mark Murphy mmur...@commonsware.com wrote:
Robert Green wrote:
I said StringBuffer but I meant Implied
couldn't you do something like:
canvas.drawText(score, x, y, paint);
canvas.drawText( POINTS_LABEL, x+30, y, paint);
so you can rid of the string concatenation.
On May 25, 11:02 pm, Robert Green rbgrn@gmail.com wrote:
I said StringBuffer but I meant Implied StringBuffer, you know:
I'm working on a small game; I decided that the best approach for my
purposes was to use char[]s internally and I wrote my own simple int-char[]
method.
As an aside, I generate and cache a set of bitmaps for the digits 0-9 and
render the score using these, rather than with the canvas drawText
Wow, I updated those string drawing methods to use a reusable
StringBuffer and it seems to have worked! I'm so happy to have
finally solved this.
Here's the code I used:
private StringBuffer scoreText = new StringBuffer(13); // it will
never be longer than 13 chars.
private void
Jason Proctor wrote:
i think Mark is saying that you could redraw the score separately
from the label, potentially saving an implicit new StringBuffer
(stuff).toString () ?
Uh. Yeah. That's what I meant. Honest.
It's not like I've never played with Android game code and therefore did
not
My new method doesn't have problems with concatenating but no solution
so far has gotten around converting an integer into a String or
CharSequence. Any time you put an integer where a String should be,
java automatically uses Integer.toString(i) to build a String out of
it which allocates a
The score changes every frame. I like how it works because it's tons
of tiny increments. I actually just did the thing I talked about with
the reusable char[]. The only caveat is that I have to allocate a new
one when the length of the string changes, but that only happens when
the score has
If you don't need thread synchronization, use StringBuilder instead of
StringBuffer.
R/
On Mon, May 25, 2009 at 3:47 PM, Robert Green rbgrn@gmail.com wrote:
The score changes every frame. I like how it works because it's tons
of tiny increments. I actually just did the thing I talked
23 matches
Mail list logo
