Hot answers tagged efficiency
25
Sort of. The shell has no idea what the commands you are running will do, it just connects the output of one to the input of the other.
If grep finds more than 10 lines that say "hello world" then head will have all 10 lines it wants, and close the pipe. This will cause grep to be killed with a SIGPIPE, so it does not need to continue scanning a very ...
11
When a program tries to write to a pipe and there is no process reading from that pipe, then the writer program receives a SIGPIPE signal. The default action when a program receives SIGPIPE is to terminate the program. A program can choose to ignore the SIGPIPE signal, in which case the write returns an error (EPIPE).
In your example, here's a timeline of ...
11
Here are some points you could start with:
Have a look at the packages installed
on your system with pacman -Q and
remove the ones you don't need. A
good start may be to append the -t
switch:
Restrict or filter output to packages
not required by any currently
installed package.
Clean the package cache of pacman
with pacman -Sc
Always use pacman ...
3
Following KISS principle, I'd just monitor free memory with free -m trying to run the same set of user apps for the same period of time. Just keep in mind, that 'cached' is actually free memory as well, so you need the 2nd line which shows what real used and free memory volumes are.
Regarding CPU — WMs usually don't hog CPU by themselves — they do that ...
3
The client-server capabilities of vim depend on X11, citing from its help:
The communication between client and server goes through the X server. The
display of the Vim server must be specified. The usual protection of the X
server is used, you must be able to open a window on the X server for the
communication to work.
[...]
A non ...
2
When you read() an inotify fd, the name field of the returned struct tells you which file was modified relative to the directory being watched, so you shouldn't have to stat every file in a directory after the event.
See http://linux.die.net/man/7/inotify
Specifically:
struct inotify_event {
int wd; /* Watch descriptor */
uint32_t ...
2
Sortof, the pipeline works like this: it first executes the first command and then the second command in your case.
That is, let's have A|B be the command given. Then it is uncertain whether A or B starts first. They might start at exactly the same time if there are multiple CPUs. A pipe can hold an undefined but finite amount of data.
If B tries to read ...
2
You can use the ondemand cpu-freq governor, as long as you set the ignore_nice_load parameter to 1.
From Documentation/cpu-freq/governors.txt, ondemand section:
ignore_nice_load: this parameter takes a value of '0' or '1'. When
set to '0' (its default), all processes are counted towards the
'cpu utilisation' value. When set to '1', the processes ...
2
As you (incorrectly – what you used is a shell pattern) mentioned it in the subject, you should use regular expressions:
find . -iregex '.*\.[ch]+'
The above is lazy approach, which will also find .ch, .hh and alike, if there exists. For exact matches you still have to enumerate what you want, but that is still easier with regular expressions:
find . ...
1
Portably/standardly (POSIX, Unix (SUS) and Linux (LSB) standards) and efficiently, you'd write it:
find . \( -name '*.cc' -o -name '*.CC' -o -name '*.[cChH]' \) \
-type f -exec grep -n -- "$1" /dev/null {} +
The most important point here is to use + instead of ;. Otherwise, you'll run one grep command per file.
The -H option is GNU specific, but adding ...
1
For each pattern, you're invoking a new instance of the sqlite program which connects to the database anew. That's a waste. You should build a single query that looks for any of the keys, then execute that one query. Database clients are good at executing large queries.
If the matching lines in the keys file only contain digits, then you can build the query ...
1
First things first, you really replace the if with a list. Actually I would even replace the [[]]s with []s, and then run in dash or other lighter sh. This even seems simple enough to ditch the entire for, and run with xargs (always my preference, better performance) So for example, maybe something like this ...
grep ^[0-9] keys | xargs -P0 -I '{id}' \
sh ...
1
grep has no direct control of the pipe (it is just receiving data), and the pipe has no direct control of grep (it is just sending data)...
What grep, or any other program does, is entirely up to that programs internal logic. If you tell grep via command line options to make an early exit-when-found, then it will, otherwise it will chug on to very end of ...
1
If being short to type is paramount and the file isn't very large:
nth_line=$(sed -n ${n}p)
nth_line=$(sed \!${n}d)
If the file is long and you're only interested in one line, use sed to print the desired line and quit, or tail to remove the previous lines and head to extract the first line of the result.
nth_line=$(sed -n -e "$n {" -e p -e q -e "}")
...
1
I would suggest AUTOMATING looking at your own very old files and see if its necessary and remove them. This can done with two things. One writing a find command to look for very old files. and using this output (maybe pipe) to lograte script to archive files older than says 3 months and delete files older than 3 months in archive and send a mail to 1 day ...
Only top voted, non community-wiki answers of a minimum length are eligible
