Does White Space Slow Down Processing

does white space slow down processing

In a word, no!

library(microbenchmark)

f1 <- function(x){
j <- rnorm( x , mean = 0 , sd = 1 ) ;
k <- j * 2 ;
return( k )
}

f2 <- function(x){j<-rnorm(x,mean=0,sd=1);k<-j*2;return(k)}

microbenchmark( f1(1e3) , f2(1e3) , times= 1e3 )
Unit: microseconds
expr min lq median uq max neval
f1(1000) 110.763 112.8430 113.554 114.319 677.996 1000
f2(1000) 110.386 112.6755 113.416 114.151 5717.811 1000

#Even more runs and longer sampling
microbenchmark( f1(1e4) , f2(1e4) , times= 1e4 )
Unit: milliseconds
expr min lq median uq max neval
f1(10000) 1.060010 1.074880 1.079174 1.083414 66.791782 10000
f2(10000) 1.058773 1.074186 1.078485 1.082866 7.491616 10000

EDIT

It seems like using microbenchmark would be unfair because the expressions are parsed before ever they are run in the loop. However using source should mean that with each iteration the sourced code must be parsed and whitespace removed. So I saved the functions to two seperate files, with the last line of the file being a call of the function, e.g.so my file f2.R looks like this:

f2 <- function(x){j<-rnorm(x,mean=0,sd=1);k<-j*2;return(k)};f2(1e3)

And I test them like so:

microbenchmark( eval(source("~/Desktop/f2.R")) ,  eval(source("~/Desktop/f1.R")) , times = 1e3)
Unit: microseconds
expr min lq median uq max neval
eval(source("~/Desktop/f2.R")) 649.786 658.6225 663.6485 671.772 7025.662 1000
eval(source("~/Desktop/f1.R")) 687.023 697.2890 702.2315 710.111 19014.116 1000

And a visual representation of the difference with 1e4 replications....
Sample Image

Maybe it does make a minuscule difference in the situation where functions are repeatedly parsed but this wouldn't happen in normal use cases.

Does excess whitespace in SQL queries affect performance?

No. The additional white space is not going to noticeably affect performance. There might be a little impact in two places:

  • The larger string might be passed through a network. So a really slow network (remember dialups?) might slow it down.
  • The tokenization phase of the compiler has to skip over white space. String processing is pretty fast these days. And just the tokenization phase is doing a lot of other work.

The cost of a select query is rarely in the compile phase anyway. Reading the data and processing it is usually where (almost) all the time is spent.

Note: You could trivially create edge cases, such as select 1 followed by or preceded by a million spaces where the compilation would be noticeable. But you would have to be intentionally creating such a query string.

Does whitespace in syntax affect performance in Python?

This was an interesting question. Basically the use of white spaces between the operands and the operator is to increase readability. It's just a matter of personal choice to add one white space or add ten. The interpreter/compiler doesn't care about white spaces. It's just about readability.

Now when you do something like this-

a = 10
b = 100
c = a + b

And when you do something like this-

a       =          10
b = 100
c = a + b

You'll notice that the first one is more readable than the second one, but this doesn't mean that the second one is wrong. It is just a matter of personal choice. Basically the convention says to follow the first method but we would get the same output with or without white spaces.

So you may use one or ten white spaces in your program, nobody can question you!!

Does having old commented code and a lot of whitespaces in code slow down performance?

No performance degradation at all. Comments are not parsed by the compiler, they are usually removed in the lexical analysis.

Does extra space slow down the processor?

Wether it slows down the process: probably to little to care about.

And simpleXML is just that, simple. If you require a 'pretty' output, DOM is your friend:

<?php
$xml = '
<xml>
<node>foo </node>
<other>bar</other>
</xml>';
$x = new SimpleXMLElement($xml);
unset($x->other);
echo $x->asXML();

$dom = new DOMDocument();
$dom->preserveWhiteSpace = false;
$dom->formatOutput = true;
$dom->loadXML($xml);
$dom->documentElement->removeChild($dom->documentElement->lastChild);
echo $dom->saveXML();

Do spaces/comments slow Javascript down?

People usually use minimizers to reduce the SIZE of the script, to improve download speed, rather than to make any difference in speed of parsing the script.

Whitespace and comments will have little effect in how long it takes a browser to execute, as the parser needs to check if it is whitespace, or a comment, but in reality this will be so minute with current computing power, it would be impossible to notice any impact.

SIZE however is still important even with the large bandwidth available in our broadband world.

will White Spaces, Comments, Empty Lines increase PHP excution time?

This is really a matter of IO and hard drive speed. If your bare file is 10KB and comments and line breaks add 4KB then the extra time that the hard drive spends reading more KB is what you need to benchmark (it's negligible by the way), not even worth your time.

If you start getting into micro-optimization then you run the risk of making your code absolutely horrid to read and maintain.

The best way to speed up your code is to re-factor code where necessary and don't do silly things that obviously hog resources like this crude example:

<?php

$arr = array(); // pretend it has 50,000 items

//GOOD IDEA: count the array once and reference that number
$arr_count = count($arr);
for($i=0; $i < $arr_count; $i++){
echo $arr[$i];
}

//BAD IDEA: re-counting the array for every iteration
for($i=0; $i < count($arr); $i++){
echo $arr[$i];
}

?>

Also unsetting a large array after you are done using it is better than waiting for the Garbage Collector to kick in. For example: pulling data from DB and looping through it. Unset the data when done and keep coding.

Last 4 Whitespaces of Sql Would Hurt Sql Server Performance?

First, the white space at the end of the query would not make a difference. It is inconceivable that white space could cause a performance problem in any database, other than lengthening the amount of time for transmitting and parsing the statement. The SQL Engine reads the query during the compile phase and produces an execution plan. The execution plan is what gets run. Extra white space is lost in the very first step of tokenizing the query string. As far as I know, all database engines work this way.

When testing performance of queries, you need to deal with the number one cause of variability in performance: caching. The second time you run a query, it will usually go much faster, because the tables are already in the page cache.

One way is to clear the cache between runs. Another is to run the query multiple times, and ignore the first run.

In any case, your first query is not proper syntax, so that might have something to do with what you are seeing. The select statement is:

select t.id1, t.sequence, t.id2, sum(t.vu) as totalVu,
sum(t.backOffPctSum) / sum(t.recordNum) as avgBackOffPct

The group by is:

group by t.testconfig_id, t.minuteSequence, t.location_id

The variables t.id1, t.sequence, and t.id2 should be causing a compile-time error in SQL Server or any reasonable database because they are neither in aggregation functions nor in the group by clause (this is a friendly dig at the hidden columns in MySQL, which would allow this syntax).



Related Topics



Leave a reply



Submit