Bug fix request: GS editor slower
First of all, I would like to say that I love GS, it is an excellent tool.
I have a suggestion to fix the GS getting slower and slower.
- Instead of saving all the actors, properties and logic in XML format I will save them in a binary GS proprietary format during the game development. That will speed the edition process and stop the editor to get slower due to memory fragmentation. I can bet you that all the problems now are inside the XML parser. Parser takes a lot of resources and creates nodes to read the XML information from an actor every time we select an actor to edit it's properties. If the XML Parser may use a garbage collector to clean it's own memory, so that can be an issue also there is memory not being cleaned properly. And because is all string manipulation that consumes a lot of resources.
- So binary is a better option, just one sequential read and GS can generate again all the internal objects for the logic of the actors in one shot. That will help a lot when we have huge projects with a lot actors and resources.
- But shall we remove XML for good? Not sure, I think this is the power of GS portability between different platforms (web, console and iPhone) So I suggest to create all the XML files in a pre-process when the user publish the game to any platform.
So that's my opinion on the matter and this is only a suggestion to be consider.
Cheers,
Emilio
I have a suggestion to fix the GS getting slower and slower.
- Instead of saving all the actors, properties and logic in XML format I will save them in a binary GS proprietary format during the game development. That will speed the edition process and stop the editor to get slower due to memory fragmentation. I can bet you that all the problems now are inside the XML parser. Parser takes a lot of resources and creates nodes to read the XML information from an actor every time we select an actor to edit it's properties. If the XML Parser may use a garbage collector to clean it's own memory, so that can be an issue also there is memory not being cleaned properly. And because is all string manipulation that consumes a lot of resources.
- So binary is a better option, just one sequential read and GS can generate again all the internal objects for the logic of the actors in one shot. That will help a lot when we have huge projects with a lot actors and resources.
- But shall we remove XML for good? Not sure, I think this is the power of GS portability between different platforms (web, console and iPhone) So I suggest to create all the XML files in a pre-process when the user publish the game to any platform.
So that's my opinion on the matter and this is only a suggestion to be consider.
Cheers,
Emilio
Comments
DO NOT REMOVE THE XML!!!
The problem is the page forward/backward metaphore they are using. It should be a tabbed document editor approach (like other IDEs). An xml parser is not the cause of the memory leak. Many good XML parsers have been written, they all work just fine and are only executed during load save. If your theory was correct then every time you saved it would slowdown the app as the only time XML is rendered is during serialization (load/save). In fact GS editor slows down every time you switch pages between actors or scenes. The slowdown is in the loading and unloading of actors into the editors. That's why it needs an editor view PER actor so you can have multiple actors and scenes open at once without flushing the editor every time. Either way, the memory leak shouldn't be there no matter what development metaphore is used.
Hook GS Editor up to Instruments under XCode and you can watch the memory leaks form.