#13730: Speed up some graph iterations
--------------------------------+-------------------------------------------
Reporter: dcoudert | Owner: jason, ncohen, rlm
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-5.10
Component: graph theory | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
--------------------------------+-------------------------------------------
Comment (by slani):
Replying to [comment:23 vdelecroix]:
> Replying to [comment:22 slani]:
> Hello,
>
> > I don't know, but I came to the conclusion that we have tow problems:
> > 1. conversion from vertex ints to vertex lables
>
> This should not slow down too much (not x4). It is a lookup in an array.
Did you make some timings to see whether this is slow ? Perhaps we have to
dig the way it is implemented.
> >
> >
> >Yes.
> >This is a timing when I'm calling iterator_out_nbrs (base/c_graph.pyx;
l: 1754)
{{{
sage: %timeit E = [(u,v) for u in G for v in G.neighbor_iterator(u)]
625 loops, best of 3: 872 µs per loop
}}}
This is a timing when I'm calling cpdef list out_neighbors
(base/sparse_graph.pyx; l:798) directly (no conversions vertex int to
vertex labels)
{{{
sage: %timeit E = [(u,v) for u in G for v in G.neighbors_three(u)]
625 loops, best of 3: 362 µs per loop
}}}
>
> > 2. how to faster return vertex ints from data structure we have for
nbrs
>
> It might be a good idea to see whether iterator over int vertices are
faster compared to the labeled one.
>
> >
> >I also trying with yield in sparse_graph.pyx
{{{
+ def iter_out_nbrs_one(self, u):
+
+ cdef int i, num_nbrs = 0, current_nbr = 0
+ cdef int size = self.out_degrees[u]
+ if self.out_degrees[u] == 0:
+ return 0
+ cdef SparseGraphBTNode **pointers = <SparseGraphBTNode **> \
+ sage_malloc(size * sizeof(SparseGraphBTNode *))
+ if not pointers:
+ raise RuntimeError("Failure allocating memory.")
+ for i from u * self.hash_length <= i < (u+1) * self.hash_length:
+ if self.vertices[i] == NULL:
+ continue
+ if num_nbrs == size:
+ sage_free(pointers)
+ return -1
+ pointers[num_nbrs] = self.vertices[i]
+ yield self.vertices[i].vertex
+ num_nbrs += 1
+
+ # While all the neighbors have not been added to the list,
explore
+ # element pointers[current_nbr] and append its children to
the end
+ # of pointers if necessary, the increment current_nbr.
+ while current_nbr < num_nbrs:
+ if pointers[current_nbr].left != NULL:
+ if num_nbrs == size:
+ sage_free(pointers)
+ return -1
+ pointers[num_nbrs] = pointers[current_nbr].left
+ yield pointers[current_nbr].left.vertex
+ num_nbrs += 1
+ if pointers[current_nbr].right != NULL:
+ if num_nbrs == size:
+ sage_free(pointers)
+ return -1
+ pointers[num_nbrs] = pointers[current_nbr].right
+ yield pointers[current_nbr].right.vertex
+ num_nbrs += 1
+ current_nbr += 1
+ sage_free(pointers)
+
}}}
> >
> >This doesn’t improve anything. I suppose this is not a good
implementation but it was just a test.
> Other possibilities
>
> 3. There are 3 levels in a graph: the `GenericGraph` class, the
`backend` (stored at `my_graph._backend`) and then the datastructure
(stored at `my_graph._backend._cg` for c graphs or
`my_graph._backend._nxg` for networkx).
>
> 4. Possibly #14690 might be a good speedup (if it works one day ;-)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13730#comment:24>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
