Skip to main content

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.

Other potential factors that may disadvantage the first are early VM initialization ocurring simultaneously, VM analysis "priming" the just-in-time compiler to allow better dynamic optimizations further along during the VM life, etc.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

There's also no reason to have two separate methods here, either; both are Set<String> -- why not make your method polymorphic?

P.S. use System.err for printing error messages rather than System.out.

P.SP.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates a total order, after all.

P.SP.SP.S. Listen to Jon and use nanoTime here :-)

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.

Other potential factors that may disadvantage the first are early VM initialization ocurring simultaneously, VM analysis "priming" the just-in-time compiler to allow better dynamic optimizations further along during the VM life, etc.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

There's also no reason to have two separate methods here, either; both are Set<String> -- why not make your method polymorphic?

P.S. use System.err for printing error messages rather than System.out.

P.S.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates a total order, after all.

P.S.S.S. Listen to Jon and use nanoTime here :-)

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.

Other potential factors that may disadvantage the first are early VM initialization ocurring simultaneously, VM analysis "priming" the just-in-time compiler to allow better dynamic optimizations further along during the VM life, etc.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

There's also no reason to have two separate methods here, either; both are Set<String> -- why not make your method polymorphic?

P.S. use System.err for printing error messages rather than System.out.

P.P.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates a total order, after all.

P.P.P.S. Listen to Jon and use nanoTime here :-)

added 5 characters in body
Source Link
obataku
  • 376
  • 2
  • 3

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.

Other potential factors that may disadvantage the first are early VM initialization happening at theocurring simultaneously, VM analysis "priming" the just-in-time compilation "priming" allowingcompiler to allow better dynamic optimizations further along during the VM life, etc.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

There's also no reason to have two separate methods here, either; both are Set<String> -- why not make your method polymorphic?

P.S. use System.err for printing error messages rather than System.out.

P.S.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates ana total order, after all.

P.S.S.S. Listen to Jon and use nanoTime here :-)

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.

Other potential factors that may disadvantage the first are early VM initialization happening at the simultaneously, just-in-time compilation "priming" allowing better dynamic optimizations further along during the VM life, etc.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

There's also no reason to have two separate methods here, either; both are Set<String> -- why not make your method polymorphic?

P.S. use System.err for printing error messages rather than System.out.

P.S.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates an total order, after all.

P.S.S.S. Listen to Jon and use nanoTime here :-)

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.

Other potential factors that may disadvantage the first are early VM initialization ocurring simultaneously, VM analysis "priming" the just-in-time compiler to allow better dynamic optimizations further along during the VM life, etc.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

There's also no reason to have two separate methods here, either; both are Set<String> -- why not make your method polymorphic?

P.S. use System.err for printing error messages rather than System.out.

P.S.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates a total order, after all.

P.S.S.S. Listen to Jon and use nanoTime here :-)

added 366 characters in body
Source Link
obataku
  • 376
  • 2
  • 3

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.

Other potential factors that may disadvantage the first are early VM initialization happening at the simultaneously, just-in-time compilation "priming" allowing better dynamic optimizations further along during the VM life, etc.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

There's also no reason to have two separate methods here, either; both are Set<String> -- why not make your method polymorphic?

P.S. use System.err for printing error messages rather than System.out.

P.S.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates an total order, after all.

P.S.S.S. Listen to Jon and use nanoTime here :-)

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

P.S. use System.err for printing error messages rather than System.out.

P.S.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates an total order, after all.

P.S.S.S. Listen to Jon and use nanoTime here :-)

I'm afraid you aren't actually reading the entire file into either Set. In fact, you're quite lucky this code isn't throwing an IOException.

while(in.readLine() != null) {
    String line = in.readLine();
    set.add(line);
}

This loop, present in both fileToHashSet and fileToTreeSet, is actually reading two lines every iteration. You're only placing every other line into either Set, which may or may not be significant. Try a loop like the below instead...

String line;
while ((line = in.readLine()) != null) {
  set.add(line);
}

Aside from that, I believe you should be timing several trials and averaging these to get a more resilient statistic. Otherwise, your results might be too influenced by other factors. Benchmark accuracy is important, right? As you have it now, you're potentially even giving an advantage to the second benchmark, since the first may require slower disk I/O, while the second might be benefit from the OS caching the file in memory.

Other potential factors that may disadvantage the first are early VM initialization happening at the simultaneously, just-in-time compilation "priming" allowing better dynamic optimizations further along during the VM life, etc.


And, lastly, a small notice... if you have two catch blocks that do identical work, only differing in exception type, I suggest you take advantage of one of the newer features of Java 7 -- catching multiple exception types. In fact, you should probably also use the (also a recent addition) try-with-resources

try (final BufferedReader in = new BufferedReader(new FileReader(path))) {
  String line;
  while ((line = in.readLine()) != null) {
    set.add(line);
  }
} catch (final FileNotFoundException | IOException ex) {
  System.err.println(ex);
}

Note you should probably not catch exceptions unless you actually plan to use them. Let them propagate out of main, where they will be printed to System.err, anyways.

There's also no reason to have two separate methods here, either; both are Set<String> -- why not make your method polymorphic?

P.S. use System.err for printing error messages rather than System.out.

P.S.S. I'll give an educated guess that HashSet will be faster than TreeSet by virtue of the underlying implementation... one necessitates an total order, after all.

P.S.S.S. Listen to Jon and use nanoTime here :-)

Source Link
obataku
  • 376
  • 2
  • 3
Loading