Improving performance of this code












0












$begingroup$


So, this code to solve Problem 23 in Project Euler (https://projecteuler.net/problem=23) gives correct answer. But, running the last expression takes around 40 seconds.



I welcome advice on how to improve performance here.



(defn sum-div [num]
(->> (range 2 (+ 1 (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
flatten
distinct
(reduce +)
(+ 1)))

(def abundants
(->> (range 12 28123)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
set))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filter #(< % num))
set)]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(->> (range 28124)
(filter (complement is-sum-of-two-abundants?))
(reduce +))









share|improve this question









$endgroup$








  • 2




    $begingroup$
    The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
    $endgroup$
    – Zeta
    Nov 5 '18 at 9:50
















0












$begingroup$


So, this code to solve Problem 23 in Project Euler (https://projecteuler.net/problem=23) gives correct answer. But, running the last expression takes around 40 seconds.



I welcome advice on how to improve performance here.



(defn sum-div [num]
(->> (range 2 (+ 1 (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
flatten
distinct
(reduce +)
(+ 1)))

(def abundants
(->> (range 12 28123)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
set))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filter #(< % num))
set)]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(->> (range 28124)
(filter (complement is-sum-of-two-abundants?))
(reduce +))









share|improve this question









$endgroup$








  • 2




    $begingroup$
    The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
    $endgroup$
    – Zeta
    Nov 5 '18 at 9:50














0












0








0


0



$begingroup$


So, this code to solve Problem 23 in Project Euler (https://projecteuler.net/problem=23) gives correct answer. But, running the last expression takes around 40 seconds.



I welcome advice on how to improve performance here.



(defn sum-div [num]
(->> (range 2 (+ 1 (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
flatten
distinct
(reduce +)
(+ 1)))

(def abundants
(->> (range 12 28123)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
set))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filter #(< % num))
set)]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(->> (range 28124)
(filter (complement is-sum-of-two-abundants?))
(reduce +))









share|improve this question









$endgroup$




So, this code to solve Problem 23 in Project Euler (https://projecteuler.net/problem=23) gives correct answer. But, running the last expression takes around 40 seconds.



I welcome advice on how to improve performance here.



(defn sum-div [num]
(->> (range 2 (+ 1 (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
flatten
distinct
(reduce +)
(+ 1)))

(def abundants
(->> (range 12 28123)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
set))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filter #(< % num))
set)]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(->> (range 28124)
(filter (complement is-sum-of-two-abundants?))
(reduce +))






performance clojure






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 5 '18 at 9:33









nakiyanakiya

1266




1266








  • 2




    $begingroup$
    The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
    $endgroup$
    – Zeta
    Nov 5 '18 at 9:50














  • 2




    $begingroup$
    The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
    $endgroup$
    – Zeta
    Nov 5 '18 at 9:50








2




2




$begingroup$
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
$endgroup$
– Zeta
Nov 5 '18 at 9:50




$begingroup$
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
$endgroup$
– Zeta
Nov 5 '18 at 9:50










1 Answer
1






active

oldest

votes


















1












$begingroup$

I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



As a last ditch effort though, I changed



(->> abundants
(filter #(< % num))
set)


to



(->> abundants
(filterv #(< % num)) ; Note the v
set)


And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



(def lower-limit 12) ; Defining these so they aren't magic,
(def upper-limit 28123) ; especially since upper-limit is used in two places

(defn sum-div [num]
(->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
(flatten) ; I personally prefer wrapping for consistency
(distinct)
(apply +) ; apply is generally regarded as more idiomatic for summing
(inc))) ; Use inc instead of (+ 1)

(def abundants
(->> (range lower-limit upper-limit)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
(set)))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filterv #(< % num))
(set))]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(time
(->> (range (inc upper-limit)) ; Use upper limit
(remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
(apply +)))

"Elapsed time: 26714.867469 msecs"
=> 4179871





share|improve this answer











$endgroup$













  • $begingroup$
    Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
    $endgroup$
    – nakiya
    Nov 7 '18 at 2:39






  • 1




    $begingroup$
    @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 2:44










  • $begingroup$
    I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
    $endgroup$
    – nakiya
    Nov 7 '18 at 3:13










  • $begingroup$
    @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 3:19













Your Answer





StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f206966%2fimproving-performance-of-this-code%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1












$begingroup$

I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



As a last ditch effort though, I changed



(->> abundants
(filter #(< % num))
set)


to



(->> abundants
(filterv #(< % num)) ; Note the v
set)


And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



(def lower-limit 12) ; Defining these so they aren't magic,
(def upper-limit 28123) ; especially since upper-limit is used in two places

(defn sum-div [num]
(->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
(flatten) ; I personally prefer wrapping for consistency
(distinct)
(apply +) ; apply is generally regarded as more idiomatic for summing
(inc))) ; Use inc instead of (+ 1)

(def abundants
(->> (range lower-limit upper-limit)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
(set)))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filterv #(< % num))
(set))]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(time
(->> (range (inc upper-limit)) ; Use upper limit
(remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
(apply +)))

"Elapsed time: 26714.867469 msecs"
=> 4179871





share|improve this answer











$endgroup$













  • $begingroup$
    Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
    $endgroup$
    – nakiya
    Nov 7 '18 at 2:39






  • 1




    $begingroup$
    @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 2:44










  • $begingroup$
    I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
    $endgroup$
    – nakiya
    Nov 7 '18 at 3:13










  • $begingroup$
    @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 3:19


















1












$begingroup$

I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



As a last ditch effort though, I changed



(->> abundants
(filter #(< % num))
set)


to



(->> abundants
(filterv #(< % num)) ; Note the v
set)


And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



(def lower-limit 12) ; Defining these so they aren't magic,
(def upper-limit 28123) ; especially since upper-limit is used in two places

(defn sum-div [num]
(->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
(flatten) ; I personally prefer wrapping for consistency
(distinct)
(apply +) ; apply is generally regarded as more idiomatic for summing
(inc))) ; Use inc instead of (+ 1)

(def abundants
(->> (range lower-limit upper-limit)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
(set)))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filterv #(< % num))
(set))]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(time
(->> (range (inc upper-limit)) ; Use upper limit
(remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
(apply +)))

"Elapsed time: 26714.867469 msecs"
=> 4179871





share|improve this answer











$endgroup$













  • $begingroup$
    Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
    $endgroup$
    – nakiya
    Nov 7 '18 at 2:39






  • 1




    $begingroup$
    @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 2:44










  • $begingroup$
    I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
    $endgroup$
    – nakiya
    Nov 7 '18 at 3:13










  • $begingroup$
    @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 3:19
















1












1








1





$begingroup$

I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



As a last ditch effort though, I changed



(->> abundants
(filter #(< % num))
set)


to



(->> abundants
(filterv #(< % num)) ; Note the v
set)


And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



(def lower-limit 12) ; Defining these so they aren't magic,
(def upper-limit 28123) ; especially since upper-limit is used in two places

(defn sum-div [num]
(->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
(flatten) ; I personally prefer wrapping for consistency
(distinct)
(apply +) ; apply is generally regarded as more idiomatic for summing
(inc))) ; Use inc instead of (+ 1)

(def abundants
(->> (range lower-limit upper-limit)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
(set)))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filterv #(< % num))
(set))]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(time
(->> (range (inc upper-limit)) ; Use upper limit
(remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
(apply +)))

"Elapsed time: 26714.867469 msecs"
=> 4179871





share|improve this answer











$endgroup$



I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



As a last ditch effort though, I changed



(->> abundants
(filter #(< % num))
set)


to



(->> abundants
(filterv #(< % num)) ; Note the v
set)


And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



(def lower-limit 12) ; Defining these so they aren't magic,
(def upper-limit 28123) ; especially since upper-limit is used in two places

(defn sum-div [num]
(->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
(flatten) ; I personally prefer wrapping for consistency
(distinct)
(apply +) ; apply is generally regarded as more idiomatic for summing
(inc))) ; Use inc instead of (+ 1)

(def abundants
(->> (range lower-limit upper-limit)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
(set)))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filterv #(< % num))
(set))]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(time
(->> (range (inc upper-limit)) ; Use upper limit
(remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
(apply +)))

"Elapsed time: 26714.867469 msecs"
=> 4179871






share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 5 '18 at 15:41

























answered Nov 5 '18 at 15:23









CarcigenicateCarcigenicate

2,86011229




2,86011229












  • $begingroup$
    Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
    $endgroup$
    – nakiya
    Nov 7 '18 at 2:39






  • 1




    $begingroup$
    @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 2:44










  • $begingroup$
    I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
    $endgroup$
    – nakiya
    Nov 7 '18 at 3:13










  • $begingroup$
    @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 3:19




















  • $begingroup$
    Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
    $endgroup$
    – nakiya
    Nov 7 '18 at 2:39






  • 1




    $begingroup$
    @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 2:44










  • $begingroup$
    I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
    $endgroup$
    – nakiya
    Nov 7 '18 at 3:13










  • $begingroup$
    @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
    $endgroup$
    – Carcigenicate
    Nov 7 '18 at 3:19


















$begingroup$
Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
$endgroup$
– nakiya
Nov 7 '18 at 2:39




$begingroup$
Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
$endgroup$
– nakiya
Nov 7 '18 at 2:39




1




1




$begingroup$
@nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
$endgroup$
– Carcigenicate
Nov 7 '18 at 2:44




$begingroup$
@nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
$endgroup$
– Carcigenicate
Nov 7 '18 at 2:44












$begingroup$
I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
$endgroup$
– nakiya
Nov 7 '18 at 3:13




$begingroup$
I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
$endgroup$
– nakiya
Nov 7 '18 at 3:13












$begingroup$
@nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
$endgroup$
– Carcigenicate
Nov 7 '18 at 3:19






$begingroup$
@nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
$endgroup$
– Carcigenicate
Nov 7 '18 at 3:19




















draft saved

draft discarded




















































Thanks for contributing an answer to Code Review Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f206966%2fimproving-performance-of-this-code%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Ottavio Pratesi

Tricia Helfer

15 giugno