Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The answer is simple, it doesn't matter. As many folks have pointed out, this is not going to be your program's bottleneck. Optimizing this to even happen instantly is unlikely to have any effect on your performance. You <strong>must profile first</strong>, otherwise you are just guessing and wasting your time.</p> <p>If we are going to waste time on it, let's at least do it right. Below is the code to do a realistic benchmark. It actually does the print and sends the benchmarking information to STDERR. You run it as <code>perl benchmark.plx &gt; /dev/null</code> to keep the output from flooding your screen.</p> <p>Here's 5 million iterations writing to STDOUT. By using both <code>timethese()</code> and <code>cmpthese()</code> we get all the benchmarking data.</p> <pre><code>$ perl ~/tmp/bench.plx 5000000 &gt; /dev/null Benchmark: timing 5000000 iterations of concat, list... concat: 3 wallclock secs ( 3.84 usr + 0.12 sys = 3.96 CPU) @ 1262626.26/s (n=5000000) list: 4 wallclock secs ( 3.57 usr + 0.12 sys = 3.69 CPU) @ 1355013.55/s (n=5000000) Rate concat list concat 1262626/s -- -7% list 1355014/s 7% -- </code></pre> <p>And here's 5 million writing to a temp file</p> <pre><code>$ perl ~/tmp/bench.plx 5000000 Benchmark: timing 5000000 iterations of concat, list... concat: 6 wallclock secs ( 3.94 usr + 1.05 sys = 4.99 CPU) @ 1002004.01/s (n=5000000) list: 7 wallclock secs ( 3.64 usr + 1.06 sys = 4.70 CPU) @ 1063829.79/s (n=5000000) Rate concat list concat 1002004/s -- -6% list 1063830/s 6% -- </code></pre> <p>Note the extra wallclock and sys time underscoring how what you're printing <em>to</em> matters as much as what you're printing.</p> <p>The list version is about 5% faster (note this is counter to Pavel's logic underlining the futility of trying to just think this stuff through). You said you're doing tens of thousands of these? Let's see... 100k takes 146ms of wallclock time on my laptop (which has crappy I/O) so the best you can do here is to shave off about 7ms. Congratulations. If you spent even a minute thinking about this it will take you 40k iterations of that code before you've made up that time. This is not to mention the opportunity cost, in that minute you could have been optimizing something far more important.</p> <p>Now, somebody's going to say "now that we know which way is faster we should write it the fast way and save that time in every program we write making the whole exercise worthwhile!" No. It will still add up to an insignificant portion of your program's run time, far less than the 5% you get measuring a single statement. Second, logic like that causes you to prioritize micro-optimizations over maintainability.</p> <p>Oh, and its different in 5.8.8 as in 5.10.0.</p> <pre><code>$ perl5.8.8 ~/tmp/bench.plx 5000000 &gt; /dev/null Benchmark: timing 5000000 iterations of concat, list... concat: 3 wallclock secs ( 3.69 usr + 0.04 sys = 3.73 CPU) @ 1340482.57/s (n=5000000) list: 5 wallclock secs ( 3.97 usr + 0.06 sys = 4.03 CPU) @ 1240694.79/s (n=5000000) Rate list concat list 1240695/s -- -7% concat 1340483/s 8% -- </code></pre> <p>It might even change depending on what Perl I/O layer you're using and operating system. So the whole exercise is futile.</p> <p>Micro-optimization is a fool's game. Always profile first and look to optimizing your algorithm. <a href="http://search.cpan.org/dist/Devel-NYTProf" rel="nofollow noreferrer">Devel::NYTProf</a> is an excellent profiler.</p> <pre><code>#!/usr/bin/perl -w use strict; use warnings; use Benchmark qw(timethese cmpthese); #open my $fh, "&gt;", "/tmp/test.out" or die $!; #open my $fh, "&gt;", "/dev/null" or die $!; my $fh = *STDOUT; my $hash = { foo =&gt; "something and stuff", bar =&gt; "and some other stuff" }; select *STDERR; my $r = timethese(shift || -3, { list =&gt; sub { print $fh $hash-&gt;{foo}, "|", $hash-&gt;{bar}; }, concat =&gt; sub { print $fh $hash-&gt;{foo}. "|". $hash-&gt;{bar}; }, }); cmpthese($r); </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POIs it faster to give Perl's print a list or a concatenated string?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSchwern
    1. USSchwern
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs it faster to give Perl's print a list or a concatenated string?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COMy system keeps telling that list is slower, even when I run your benchmark. This also shows that you can't choose one of these variants: while on some system the former is faster, on others the latter is.
      singulars
      1. PO
      1. USP Shved
    2. COPlease, stop wasting on putting up experiments like this. They've been done millions of times. The performance difference doesn't matter.
      singulars
      1. PO
      1. USAlex Weinstein
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload