Search Results

Search found 2 results on 1 pages for 'aperion'.

Page 1/1 | 1 

  • Divide and conquer of large objects for GC performance

    - by Aperion
    At my work we're discussing different approaches to cleaning up a large amount of managed ~50-100MB memory.There are two approaches on the table (read: two senior devs can't agree) and not having the experience the rest of the team is unsure of what approach is more desirable, performance or maintainability. The data being collected is many small items, ~30000 which in turn contains other items, all objects are managed. There is a lot of references between these objects including event handlers but not to outside objects. We'll call this large group of objects and references as a single entity called a blob. Approach #1: Make sure all references to objects in the blob are severed and let the GC handle the blob and all the connections. Approach #2: Implement IDisposable on these objects then call dispose on these objects and set references to Nothing and remove handlers. The theory behind the second approach is since the large longer lived objects take longer to cleanup in the GC. So, by cutting the large objects into smaller bite size morsels the garbage collector will processes them faster, thus a performance gain. So I think the basic question is this: Does breaking apart large groups of interconnected objects optimize data for garbage collection or is better to keep them together and rely on the garbage collection algorithms to processes the data for you? I feel this is a case of pre-optimization, but I do not know enough of the GC to know what does help or hinder it.

    Read the article

  • assign member based on string value

    - by Aperion
    I need start off with code because I am not sure what terminology to use. Lets say I have the following code: class Node { public: void Parse(rapidxml::xml_node<> *node) { for (rapidxml::xml_attribute<> *attr = node->first_attribute(); attr; attr = attr->next_attribute()) { std::stringstream converter; converter << attr->value(); if( !strcmp(attr->name(), "x") ) converter >> x; else if( !strcmp(attr->name(),"y") ) converter >> y; else if( !strcmp(attr->name(), "z") ) converter >> z; } } private: float x; float y; float z; }; What I can't stand is the repetition of if( !strcmp(attr-name(), "x") ) converter x; I feel that this is error prone and monotonous, but I cannot think of another way to map a string value to a member assignment. What are some other approaches one can take to avoid code such as this? The only other possible alternative I could think of was to use a hashmap, but that runs into problems with callbacks This is the best I could up with but it's not as flexible as I'd like: class Node { Node() : x(0.0f), y(0.0f), z(0.0f) { assignmentMap["x"] = &x; assignmentMap["y"] = &y; assignmentMap["z"] = &z; } public: void Parse(rapidxml::xml_node<> *node) { for (rapidxml::xml_attribute<> *attr = node->first_attribute(); attr; attr = attr->next_attribute()) { if( !attr->name() ) continue; std::stringstream converter; converter << attr->value(); converter >> *assignmentMap[attr->name()]; } } private: float x; float y; float z; std::map<std::string, float*> assignmentMap; };

    Read the article

1