Rockbox General > Rockbox General Discussion

Optimizing Rockbox Sources

<< < (6/6)

Llorean:
Why do you want to allocate for "the system" dynamically. What buffers that the system currently use, do you feel could be larger?

Sentertainment:

--- Quote from: Llorean on January 01, 2007, 07:42:01 PM ---Why do you want to allocate for "the system" dynamically. What buffers that the system currently use, do you feel could be larger?

--- End quote ---

I don't want to do that to make it larger, no current need for that (at the moment).
Reason being is the code can be restructured in such a way that loops wouldn't be needed for commands such as menu_find_free() wouldn't require loops...and possibly not even be needed at all if done correctly.
The reason I brought this whole idea of dynamic allocation up is because it would allow for greater optimization of certain functions.
(dynamic allocation could allow for array keys to be removed fast and eifficiently, or even relocated to an alternate array to identify them as being inactive rather than using 'for' loops to scan through the arrays like that)

Maybe now that I've (hopefully) explained it better, either you can come up with a better comeback or agree with me....either way, as long as I get some feedback I'll be happy. :P

safetydan:
To me it seems like you're looking at optimising the wrong areas. The menu code snippet you've posted is unlikely to be the bottle neck for any performance issues you've seen. Bigger issues (particularly for iPods) are just the time it takes to redraw the screen (or was last I heard).

You keep saying that you want to "optimise" Rockbox, but haven't actually pointed to any areas that are actually measured to be slow. Maybe start by profiling things to find bottlenecks rather than guessing and proposing massive changes to memory handling to fix a problem that may not even be a problem. Heck, I think Rockbox already has a profiling system, though I'm not sure what state it's in. Start there.

sloth:

--- Quote ---Reason being is the code can be restructured in such a way that loops wouldn't be needed for commands such as menu_find_free() wouldn't require loops...and possibly not even be needed at all if done correctly.
--- End quote ---

Not really.  There would be a loop, or equivalent, it would just be hidden away inside of malloc.

I can agree with both sides of the malloc issue, but on the whole I think the RB devs have it right and doing things as statically as possible is a very good thing, especially as parts of the system are quasi realtime.

And the argument that it makes and already difficult debugging task that much easier make a lot of sense.

Navigation

[0] Message Index

[*] Previous page