From: cee1 <fy...@gm...> - 2016-02-01 13:23:47
|
Hey, I've opened an issue and ... When trying the way of "rewriting the priorities* after the sort() in flow" I found it needs to rewrite priorities of all interface cells, instead of those have relations attached and unresolved. So the following code snippet: """ // Generate the set of cells connected to unresolved relations vector<cell_t*> cells; for (relation_cell_set_t::iterator f(relation_cell_set_m.begin()), l(relation_cell_set_m.end()); f != l; ++f) { if (!f->resolved_m) cells.insert(cells.end(), f->edges_m.begin(), f->edges_m.end()); } sort(cells); cells.erase(unique(cells), cells.end()); """ Is replaced with: """ // Generate the set of (output) interface cells vector<cell_t*> cells; for (index_t::iterator f(output_index_m.begin()), l(output_index_m.end()); f != l; ++f) { if ((*f)->specifier_m == access_interface_output) cells.insert(cells.end(), *f); } """ Now **cells** contain all interface cells(output part), and the priority_accessed bits is set as follows: """ for (vector<cell_t*>::iterator f = cells.begin(), l = cells.end(); f != l; ++f) { if ((*f)->relation_count_m != 0) priority_accessed.set((*f)->interface_input_m->cell_set_pos_m); """ Any idea? Did I miss something? BTW, I found name_t is actually a mapping from a `hash code' to a `pointer of where the string is stored'. """ name_t() in adobe/name.hpp → map_string() in source/name.cpp typedef std::unordered_map<std::size_t, const char*> map_t; ... static map_t map_s; ... return found == map_s.end() ? map_s.emplace(hash, pool_s.add(str)).first->second : found->second; """ It seems to me above code is incorrect when a hash collision happens - different strings with the same `hash code' share a single `pointer', right? 2016-01-22 12:47 GMT+08:00 Sean Parent <sea...@ma...>: > Hi cee1, > You might move this to an issue on github. Manipulating a list would require > an index or search and a fair amount of machinery. > > Two simpler fixes - > 1) Declare priority_t as int64_t. At 60 transactions per/second that gives > you 4 billion years before overflow. > 2) Rewrite the priorities and priority_high_m and _low_m after the sort() in > flow > > (2) could be done only if high or low exceeds some threshold but I don't > think I'd include that optimization without some measurements to show value. > > You could also not increment high or low if the cell be set is already at > the limit - but that seems like an unnecessary pessimization for only > theoretical safety, > > Send me a PR for either! > > Sean > > On Thu, Jan 21, 2016 at 6:32 PM, cee1 <fy...@gm...> wrote: >> >> Hi all, >> >> I notice each time touch/set a cell, priority_high_m is increased and >> its value is assigned to >> cell's priority_m field. >> >> So theoretically, it's possible to overflow priority_high_m, right? E.g. >> >> Considering in an automated UI test, (only) a text entry is frequently >> updated, the priority_m of the backed cell is continuously increased, >> and will finally overflow. >> >> The priority_m is (only) used in flow(): to sort the cells, and >> process the relations attached to a cell one by one, right? >> In other words, only the sequence is cared, not the distance. >> >> >> So what about maintaining a `priority list', if a cell is touched/set, >> move to .begin() ? >> >> Moreover, it may change type of the priority_m to a pointer of `link >> node of the list', then if a cell is touched/set, it will be unlinked, >> and reinserted to .begin() quickly. >> >> >> >> -- >> Regards, >> >> - cee1 >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> _______________________________________________ >> Adobe-source-devel mailing list >> Ado...@li... >> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- Regards, - cee1 |