-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speed up preprocessing? #35
Comments
On Sun, Nov 15, 2020 at 08:29:48AM -0800, Philipp Klaus Krause wrote:
Would it be possible to improve speed here somehow?
I can think of several ways. The plan was to create an interface to the
preprocessor, and then try other implementations. It never happened, but
there are some traces in the code hinting at how to do it.
It is also well possible that the bottleneck moves to another place when
using a different adjacency structure. linked lists tend to be
relatively slow for smaller degree.
|
Can you please report on runtime for PP, PP_FI and PP_FI_TM separately such that we know how much time is spent in the subalgorithms? The complexity of clear_vertex depends on the edge set type chosen. What graph type are you using? |
I can only reproduce this at -O1. So I do not know how much of a problem there is at -O2 vs. me just not being able to read the information at -O2 due to stuff not being visible in valgrind. Relative (to treedec::comb::PP_FI_TM) runtime: treedec::comb::PP_FI_TM) is called from three places, relative runtime: In each case, a tree-decomposition of a cfg is computed. The cfg is first copied into a cfg2_t, which is then passed to treedec::comb::PP_FI_TM.
|
This should improve with vector based adjacency list, as these are manipulated in-place.
Should do and make use of boost::erase_if. I will make sure this works and add a test as soon as I can. Also, please check if you specified NDEBUG during compilation. Omitting it will result in a debug mode build which may be an order of magnitude slower. |
For one of the largest function in the standard library that comes with SDCC, printf, treedec::comb::PP_FI_TM takes much longer to get a tree decomposition than Thorup.
According to valgrind, at -O1, 71 % of the time spent in treedec::comb::PP_FI_TM is just for the boost::clear_vertex call in line 293 of preprocessing.hpp (the call that has the // expensive? comment directly above it).
Would it be possible to improve speed here somehow?
The text was updated successfully, but these errors were encountered: