|
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
|