How to debug slow Ember CLI/Broccoli builds - ember-cli

My Ember CLI project is currently taking 8-9 seconds to build, and I'd like to understand why. The project is not that large (~180 files under app/ including hbs and scss).
Here's my brocfile: https://gist.github.com/samselikoff/874c90758bb2ce0bb210
However, even if I comment my entire Brocfile out and export just the app variable, the build still takes 5-6 seconds.
I'm not quite sure how debug. Here's my slowest tree logs:
Build successful - 8874ms.
Slowest Trees | Total
-------------------------------+----------------
TreeMerger (appAndDependencies)| 1286ms
TreeMerger (vendor) | 1275ms
CompassCompiler | 1204ms
StaticCompiler | 1185ms
TreeMerger (stylesAndVendor) | 1151ms
TreeMerger (allTrees) | 706ms
StaticCompiler | 625ms

UPDATE: If you are using ember-cli version 0.1.0 or newer, this hack is probably not necessary. ember-cli now symlinks files instead of copying. You may still get a performance improvement on windows or slow disks.
Broccoli (used by ember-cli) stores its temporary state in the file system, thus it's very file I/O dependent. Try to reduce the number of files in your public/, vendor/ and bower_components/ directories. All files inside these folders will be copied at least once per rebuild cycle. The size and number of files in the folders affects performance greatly.
Essentially, every time you change a file, broccoli is copying files between the many directories inside <ember app>/tmp/. In the case of your bower_components/ dir, it appears to be copying every single file more than once. It needs to do this because you might use app.import('some.js') in your Brocfile.js, you might also #import "some.scss" in SASS/LESS files. There is no way to know which files you actually need, so it copies all of them.
If you remove the files that you do not need from bower_components/ and vendor/, you will notice better build times.
A real world example
If you install the highcharts.com#3.0.5 bower dependency, you also get a special gift of 2829 files (198MB) in your bower_components/ dir. Imagine the unnecessary file system reads and copies that are happening there.
Here is a snippet of my cleaned dir structure:
$ find bower_components -type f | grep highcharts
bower_components/highcharts.com/js/highcharts-more.src.js
bower_components/highcharts.com/js/highcharts.src.js
Notice that only the .js files remain, I removed everything else. That's 2827 removed files. Highcharts is an extreme example, but most of your dependencies have 5 times as many files than you actually need.
Positive future ahead
The ember-cli team are hard at work improving performance of the underlying broccoli ecosystem. Work has already begun and some real world apps (with large trees) are seeing performance improvements reducing rebuild time from 4 seconds to 600ms. Using symlinks instead of copying is showing drastic improvements.
For those of us who have large scale apps, lots of bower deps and many crying team members, who need a solution now:
A temporary solution
One way of keeping your bower_components/ clean, is to check the dependencies into version control. This allows you to use git clean to prune your directory with ease:
bower install —-save d3
git add -—force bower_components/d3/d3.js # force, because bower_components/ is gitignored
git commit -m "Added d3.js"
// Brocfile.js
app.import('bower_components/d3/d3.js');
Every time you do a bower install you will likely get all the extra cruft back in your dir. git clean easily removes non version controlled files:
git clean -f -d -x bower_components/
ember serve
After doing this, it took a single rebuild (time to build after changing a file) from 20 seconds down to 3.5 seconds (we have a pretty large app).
If you do go this path, dont forget the bower deps needed by Ember:
bower_components/ember/ember.js
bower_components/ember/ember.prod.js
bower_components/ember-cli-shims/app-shims.js
bower_components/ember-cli-test-loader/test-loader.js
bower_components/ember-data/ember-data.js
bower_components/ember-data/ember-data.prod.js
bower_components/ember-load-initializers/ember-load-initializers.js
bower_components/ember-resolver/dist/modules/ember-resolver.js
bower_components/jquery/dist/jquery.js
bower_components/loader/loader.js
bower_components/handlebars/handlebars.js
bower_components/handlebars/handlebars.runtime.js
Here's the git command for you:
bower install
git add -f bower_components/ember/ember.js bower_components/ember/ember.prod.js bower_components/ember-cli-shims/app-shims.js bower_components/ember-cli-test-loader/test-loader.js bower_components/ember-data/ember-data.js bower_components/ember-data/ember-data.prod.js bower_components/ember-load-initializers/ember-load-initializers.js bower_components/ember-resolver/dist/modules/ember-resolver.js bower_components/jquery/dist/jquery.js bower_components/loader/loader.js bower_components/handlebars/handlebars.js bower_components/handlebars/handlebars.runtime.js
git commit -m "Added ember-cli dependencies"
git clean -f -d -x bower_components/

In addition to #tstirrat's answer:
Only running as administrator will allow You to use symlinks files
(Default SeCreateSymbolicLinkPrivilege flag) try running cmd (or PowerShell) as administrator and see if it helps.
You can allow it for specific user using Local Policies configuration.
Answer taken from here

Related

VSC unable to watch for file changes in this large workspace weird

I just started using VSCode version 1.24.1.
After loading a folder, it shows warning
Visual Studio Code is unable to watch for file changes in this large workspace
After i check the limit as suggested on their guide, using
cat /proc/sys/fs/inotify/max_user_watches
I get 8192, while my project has only 650 files (of which 400 are inside .git)
Why does this happen? Is this a bug or am I missing something?
(Increasing the limit is clearly not the right solution.)
what linux ppl dont know, there are ppl new to linux like me. So if you're a noob, this is for you.
Open a new terminal.
cat /proc/sys/fs/inotify/max_user_watches (might be a number 8k+)
now (a) for vim-Editor
(a) sudo vim /etc/sysctl.conf
(a) go all the way down and add a new line with: fs.inotify.max_user_watches=524288 (make sure you DONT have a # in front of the command)
(a) type :wq! and press enter
or (b) for nano-Editor (thanks to #bradrar)
(b) sudo nano /etc/sysctl.conf
(b) go all the way down and add a new line with: fs.inotify.max_user_watches=524288 (make sure you DONT have a # in front of the command)
(b) type ctrl + x, type y and press enter
type sudo sysctl -p
type again: cat /proc/sys/fs/inotify/max_user_watches (should be 500k+ now)
(thank me later.)
The solution I found and it's work for me is
add this line fs.inotify.max_user_watches=524288 in to /etc/sysctl.conf
and then run the command sudo sysctl -p
and then go to your vscode settings find a file called settings.json
and this line to it
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/*/**": true
}
you can also refer this link https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc
The fact that you are out of watches does not mean that its VSCode's fault.
VSCode has for sure issues with excluding directories from watch (on linux) (update: most are recently resolved here, and here)
But since you have counted the files yourself, the error message in this case is probably misleading and some other application has already exhausted watches.
To trace the guilty app you can use this nice script
In my case I do not have enough privileges to change the sysctl.conf, so my solution for Ubuntu 18.04 LTS was:
sudo /bin/su -c "echo 'fs.inotify.max_user_watches=524288' >> /etc/sysctl.conf"
sudo sysctl -p
In my case (PHP using Composer), I had to exclude vendor path from watching
Depending on your case, you should exclude your dependencies folder.
Following settings worked for me (inside .vscode/settings.json, you can also put them at user level / system level settings in vscode instead of workspace level settings)
"files.watcherExclude": {
"**/.git": true,
"**/.DS_Store": true,
"**/node_modules": true,
"**/some-soft-link-to-higher-level-directory-in-my-file-system" : true,
"**/.cache-loader" : true
}
.git, node_modules are perhaps excluded by default, but depending on your workspace, you may need to add others. As an example, I had a soft link to a higher level directory in my file-system (which recursively had 100s of thousands of files). Similarly, .cache-loader often has thousands of files.
Possibly useful note: it took me some time to realize that files.exclude and files.watcherExclude are two different settings.
Some theoretical opinion: Most answers here (and even in the official vscode documentation) suggest increasing the system watcher limits to a very large number. This works okay in most cases, however, it is like using a hammer in place of a screwdriver (is brute force, may not always work, and is not efficient). While the absolute system limit can (and perhaps should be) raised from the default limit, it is beneficial to optimize your workspace and avoid using unnecessary system resources.
Here is the solution : https://code.visualstudio.com/docs/setup/linux
The limit can be increased to its maximum by editing /etc/sysctl.conf and adding this line to the end of the file: fs.inotify.max_user_watches=524288
The new value can then be loaded in by running sudo sysctl -p
Oct. 2021: this is improved from VSCode 1.61 (Sept. 2021, see below)
VSCode 1.62 includes:
File watching changes
File watching in VS Code changes to a new library, thanks to the work of the Parcel team with their #parcel/watcher.
We will gradually roll out this change to all users in the upcoming weeks.
Linux users will be happy to learn that the files.watcherExclude now applies natively so that the number of file handles VS Code needs to open for file watching can be greatly reduced.
The existing files.legacyWatcher setting was changed to an enumeration with these values:
on - The new file watcher will never be used.
off - The new file watcher will always be used.
default - The new file watcher will only be used when you open multi-root workspaces (via .code-workspace file).
Feb. 2021: As noted in issue 40898, the issue persists for the multi-root workspace (see the last part, for VSCode 1.61 improvements)
Initial problem is that the npm install takes twice as long to install dependencies when VSCode is running.
I've figured out that this is because of file watching for the node_modules folder so I added it to files.watcherExclude.
I use the following combinations (but non of them seems to be working):
"files.watcherExclude": {
"**/node_modules": true,
"**/node_modules/**": true,
"**/node_modules/*/**": true
}
This comment points out a script from Dirk Feytons to see which inotify watches are actually being created to confirm whether my watcher excludes were being used or not.
/*
* If you want to see which inotify watches are being created by an application then you can
* use this simple piece of code, compile it to a shared library and LD_PRELOAD it when starting
* the application. Keep an eye on syslog to see the list of watches.
* **NOTE**: This only logs the watches, it won't actually create the watch and thus watching
* for changes WON'T actually WORK!
*
* More details (adjust as needed for your environment/distribution):
* - Save this file in e.g. $HOME/inotify.c
* - Compile: gcc -shared -o inotify.so inotify.c
* - Start monitoring syslog: tail -f -n 0 /var/log/syslog | tee $HOME/watches.log
* - Run your application with: LD_PRELOAD=$HOME/inotify.so <application>
*/
#include <sys/inotify.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <syslog.h>
int inotify_add_watch(int fd, const char *pathname, uint32_t mask)
{
syslog(LOG_USER | LOG_ERR, "********** [%u] inotify_add_watch for %s", getpid(), pathname);
return 100000;
}
Update Sept. 2021, from Lionel Gatibelza:
I was able to fix the problem, I don't know the real cause and why Vscode performed this check for the error, but I did the known fix on the remote server and on my local machine:
Add this fs.inotify.max_user_watches=524288 to /etc/sysctl.conf
Reload the configuration: sudo sysctl -p
Close and reopen vscode
After that I didn't have the error again!
And from issue 132483 from Benjamin Pasero (software engineer at Microsoft in Zurich):
Just to clarify, nsfw is used on Windows as well in multi-root workspaces.
It was our original intent 5y ago to replace all other watching solutions with nsfw so we enabled it only for multi-root scenarios, which target a lower user base (maybe 200.000 users) to get some testing and feedback.
The next step in this journey is to enable it for all users and remove the others.
PS: the only platform where nsfw is currently not enabled by default (unless you are in a multi-root workspace) is Linux because unfortunately nsfw does not support ignore patterns (our files.watcherExclude setting) and each folder in a hierarchy is counted as an opened file handle against the limited set of file handles in the OS, forcing users to increase that limit.
The plan is to implement that support in October and then also get Linux on board.
Sept. 2021, VSCode 1.61:
File watching changes
The file watcher used to detect changes to files and folders on disk changed to a library that can handle all of our supported platforms (Windows, Linux, macOS) and reduces the overhead of maintaining different watchers for different platforms.
We plan to enable this library by default on all platforms. This iteration we enabled it on Windows and macOS, while Linux is planned shortly after.
The new watcher should be faster on startup, resulting in fewer CPU cycles spent on large folders.
One downside of using the library is that the file watcher no longer automatically detects folders in a workspace that are symbolic links on macOS.
If you have such a setup, you can use the new files.watcherInclude setting to add symbolic link paths to include for file watching explicitly.
On the upside, you can use this new setting on Windows to explicitly include symbolic link folders inside the workspace - something that was not possible before on Windows.
You should not notice any difference in your day to day work, but if file watching is broken for you, please report an issue.
There is a setting files.legacyWatcher to enable the old watcher in case of problems.
What helped me was creating a separate workspace for the project i was working on. So if i'm working on something in /htdocs/project/ then instead of just opening that folder i create it as a workspace.
TL; DR;
Seems like a bug.
-----
It seems the warning is gone now.
Unfortunately I cannot reproduce the bug right now, but here are some steps.
Installed Php Intellisense extension
From linux terminal did git init
Added folder into workspace
Did some work, added, saved, commit and push from command palette
closed VSC
Opened VSC -> warning was shown.
At this moment i saw in htop that there was a process /usr/share/code with long arguments which included something with TypeScript that was using 100% of 1 CPU and around 1G RAM. Then
closes VSC
killed process
opened VSC
Now the warning is not showing anymore, also CPU is being used normally.
I followed the recommendations from
https://stackoverflow.com/users/4270633/harsh-shah[harsh-shah][1]
Almost worked for me. I discovered I had resources in my project that were also being watched unnecessary.
VScode behavior seems to be watch everything, unless excluded.
If you find you have a couple hundred files in your project but have 32000 watchers - you may want to inventory what is in your project directory and exclude unnecessary directories.
For those using Pylance, setting "files.watcherExclude" may not suffice. The extension watches all paths reported by python sys.path.
source: https://github.com/microsoft/pylance-release/issues/2914#issuecomment-1154254992
Deactivating the extension is one, admittedly imperfect, solution if increasing max_user_watches is not an options.
If you are using for JavaScript development, there is a workaround:
Just disable this built-in extension: TypeScript and JavaScript Language Features
Raising the file limits of the system really only papers over the problem.
Are you really going to raise the watcher limit over the 100s of thousands that it already is at?
Instead, search in the repo for folders with a tone of files in them:
du --inodes -S | sort -rh | sed -n \
'1,50{/^.\{71\}/s/^\(.\{30\}\).*\(.\{37\}\)$/\1...\2/;p}'
vscode should already exclude node_modules and .git by default, so it is probably other folders that you have, likely auto-generated files from some app (a compilation or directory target, etc).
This one ignores .git and node_modules directories:
du --inodes -S | grep -v "node_modules" | grep -v ".git" | sort -rh | sed -n \
'1,50{/^.\{71\}/s/^\(.\{30\}\).*\(.\{37\}\)$/\1...\2/;p}'
You could also just remove recursively your node_modules if you are confident in running a fresh npm install. To remove:
find . -name 'node_modules' -type d -prune -exec rm -rf '{}' +
If you are writing Javascript, then this is probably gonna work for this issue:
You have to access the side-bar extensions menu: Ctrl + Shift + X.
Then type: #builtin types and disable the extension: TypeScript and JavaScript language features.

how to delete deploy/images/beaglebone dir in yocto

In my yocto source deploy/images/beaglebone dir is nearly 100GB so i want to free that memory
Please help me how can I delete that deploy dir either manually or via command line
I want to clean all images(*.tar.gz,*.sdcard, *.ubifs) of previous compilation in yocto deploy/images/beaglebone/
Maybe when you are with 100GB in the deploy directory, things have gone too far already.
Check your IMAGE_FSTYPES variable. My experience says it is safe to delete all images of these files that are not symlinks, or symlinks targets. Avoid the last one generated to avoid breaking the last build link, and any related with bootloaders and configuration files, as they could be rarely regenerated.
If you are keeping more than one build with the same set of layers, then you can use a common download folder for builds.
DL_DIR ?= "common_dir_across_all_builds/downloads/"
And afterwards:
To keep your /deploy clean:
RM_OLD_IMAGE: Reclaims disk space by removing previously built versions of the same image from the images directory pointed to by the DEPLOY_DIR variable.Set this variable to "1" in your local.conf file to remove these images:
RM_OLD_IMAGE = "1"
IMAGE_FSTYPES Remove the image types that you do not plan to use, you can always enable a particular one when you need it:
IMAGE_FSTYPES_remove = "tar.bz2"
IMAGE_FSTYPES_remove = "rpi-sdimg"
IMAGE_FSTYPES_remove = "ext3"
For /tmp/work, do not need all the workfiles of all recipes. You can specify which ones you are interested in your development.
RM_WORK_EXCLUDE:
With rm_work enabled, this variable specifies a list of recipes whose work directories should not be removed. See the "rm_work.bbclass" section for more details.
INHERIT += "rm_work"
RM_WORK_EXCLUDE += "home-assistant widde"
try this from your build root rm -fr deploy/images. Here is a good discussion on the topic
I just removed the files manually like below
1. goto build/deploy/images/beaglebone
2. $ ll : you will find the softlinks of rootfs with time like
......*20170811091521.rootfs.tar.gz
......*-20170811091521.rootfs.sdcard etc
3. Dont delete recently compiled files. except these this you can remove all *.tar.gz, *.sdcard,*.ext4 manually like below,
4. rm beaglebone-20170811091521.rootfs.tar.gz
rm beaglebone-20170811091521.rootfs.sdcard
rm beaglebone-20170811091521.rootfs.ext4 etc.

Add a local dependency to an ACI in acbuild

I'm currently experimenting with ACI construction for rkt-containers. During my experiments I've built some containers especially for the use as a dependency. I now want to use these .aci images as a dependency for other images. As these files are fetched by name (for example "quay.io/alpine-sh"), I wonder if there is a way to refer to actual local .aci files.
Is there a way to import these .aci files from the local filesystem or do I have to set up a local webserver to serve as a repository?
Dependencies in acbulid (at least till version 0.3) can be defined only as http-links,
so you need to make your aci available through http to use it as dependency in acbuild.
It's not so hard to publish your aci to make it available through http. Image archive can be actually hosted on github or bitbucket.
The recent versions of acbuild seem to support it
since the relating issue (cache dependencies across acbuild invocations #144) is closed.
Cached ACI's are stored in directories depstore-tar and depstore-expanded inside $CONTEXT_ROOT/.acbuild. If we save somehow content of those directories between acbuild init,
acis won't be downloaded over and over again.
When i played with acbuild i was so annoyed that acbulid redownloads dependencies on every build.
I've written script https://bitbucket.org/legeyda/anyorigin/src/tip/acbuild-plus
which configures symbolic links inside $CONTEXT_ROOT/.acbuild to point to
persistence directories inside /var/lib/acbuild/hack. The usage is simple:
acbuild begin
acbuild-plus init target
After that all dependencies will be cached by acbuild.
You can also manually install aci-file to be available to acbuild.
This is as simple as
acbulid-plus install <your-image.aci>
I've tested the script with acbuild v0.3.0.
You can get an example of using it in the Makefile next to acbuld-plus in the repository.

how to reduce GWT war file size

i am using ExtGWT. my application has 5 modules. in war folder all five modules will be compiled and placed. but in every module resources folder is common. my intention is keeping resources folder common. so that the generated war size can be decreased. plz suggest me.
Thanks,
David
Perhaps not exactly, what you are asking for, but I guess, you don't want to upload everytime everything since the amount of data is quite large.
I do it this way:
- DON't create a war-file.
- simply use rsync to incrementally deploy the contents of the war-directory of your GWT-project like this:
rsync -avc --compress --progress --delete --rsh='ssh' --cvs-exclude
./war
root#serverip:/usr/share/tomcat7/webapps/ROOT/
So, only newer files gets uploaded to the server and remaining old files which are not used anymore gets deleted from the server.
Hoped this helped you.

Can you "ignore" a file in Perforce?

I sometimes use the feature 'Reconcile Offline Work...' found in Perforce's P4V IDE to sync up any files that I have been working on while disconnected from the P4 depot. It launches another window that performs a 'Folder Diff'.
I have files I never want to check in to source control (like ones found in bin folder such as DLLs, code generated output, etc.) Is there a way to filter those files/folders out from appearing as "new" that might be added. They tend to clutter up the list of files that I am actually interested in. Does P4 have the equivalent of Subversion's 'ignore file' feature?
As of version 2012.1, Perforce supports the P4IGNORE environment variable. I updated my answer to this question about ignoring directories with an explanation of how it works. Then I noticed this answer, which is now superfluous I guess.
Assuming you have a client named "CLIENT", a directory named "foo" (located at your project root), and you wish to ignore all .dll files in that directory tree, you can add the following lines to your workspace view to accomplish this:
-//depot/foo/*.dll //CLIENT/foo/*.dll
-//depot/foo/.../*.dll //CLIENT/foo/.../*.dll
The first line removes them from the directory "foo" and the second line removes them from all sub directories. Now, when you 'Reconcile Offline Work...', all the .dll files will be moved into "Excluded Files" folders at the bottom of the folder diff display. They will be out of your way, but can still view and manipulate them if you really need to.
You can also do it another way, which will reduce your "Excluded Files" folder to just one, but you won't be able to manipulate any of the files it contains because the path will be corrupt (but if you just want them out of your way, it doesn't matter).
-//depot/foo.../*.dll //CLIENT/foo.../*.dll
Yes, But.
Perforce version 2012.1 added a feature known as p4ignore, inspired by Git. However the Perforce developers made a change to the behaviour, without justification, that happens to make the feature a lot less useful.
Whilst Git takes rules from all .gitignore files, Perforce doesn't know where to look until you specify a filename in an environment variable P4IGNORE. This freedom is a curse. You can't hack on two repositories that use different names for their ignore files.
Also, Perforce's ignore feature doesn't work out the box. You can set it up easily enough for yourself, but others don't benefit unless they explicitly opt-in. A contributor who hasn't may accidentally commit unwelcome files (eg. a bin folder created by a build script).
Git's ignore feature is great because it works out the box. If the .gitignore files are added to the repository (everyone does this), they'll work out the box for everyone. No-one will accidentally publish their private key.
Amusingly, the Perforce docs shows '.p4ignore' as an example ignore rule, which is backwards! If the rules are useful, they should be shared as part of the repository.
Perforce could still make good on the feature. Choose a convention for the file names, say p4ignore.txt, so the feature works out the box. Drop the P4IGNORE environment variable, it's counterproductive. Edit the docs, to encourage developers to share useful rules. Let users write personal rules in a file in their home folder, as Git does.
If you know anyone at Perforce, please email them this post.
This works as of Perforce 2013.1, the new P4IGNORE mechanism was first added in release, 2012.1, described on the Perforce blog here:
https://www.perforce.com/blog/new-20121-p4ignore
As it's currently described, you set an environment variable "P4IGNORE" to a filename which contains a list of the files to ignore.
So you can check it out to see how you like it.
If you want a solution that will apply to all work-spaces without needing to be copied around, you (or your sysadmin) can refuse submission of those file-types through using lines like the below in the p4 protect table:
write user * * -//.../*.suo
write user * * -//.../*.obj
write user * * -//.../*.ccscc
I remember doing this before, but I don't have the necessary permissions to test this here. Check out Perforce's Sysadmin guide and try it out
Perforce Streams makes ignoring files much easier, as of version 2011.1. According to the documentation, you can ignore certain extensions or certain paths in your directory.
From p4 help stream
Ignored: Optional; a list of file or directory names to be ignored in
client views. For example:
/tmp # ignores files named 'tmp'
/tmp/... # ignores dirs named 'tmp'
.tmp # ignores file names ending in '.tmp'
Lines in the Ignored field may appear in any order. Ignored
names are inherited by child stream client views.
This essentially does what #raven's answer specifies, but is done easier with streams, as it automatically propagates to every work-space using that stream. It also applies to any streams inheriting from the stream in which you specify the ignore types.
You can edit the stream via p4 stream //stream_depot/stream_name or right-clicking the stream in p4v's stream view.
And as #svec noted, the ability to specify ignore files per workspace is coming soon, and is in fact in P4 2012.1 beta.
Will's suggestion of using .p4ignore only seems to work with the WebSphere Studio (P4WSAD) plugin. I just tried it on my local windows box and any files and directories that I listed were not ignored.
Raven's suggestion of modifying your client spec is the correct way under Perforce. Proper organization of your code/data/executables and generated output files will make the process of excluding files from being checked in much easier.
As a more draconian approach, you can always write a submit trigger which will reject submission of change-lists if they contain a certain file or files with a certain extension, etc.
HISTORICAL ANSWER - no longer correct. At the time this was written originally it was true;
You can not write and check in a file that the server will use to make ignore rules; general glob or regexp file pattern ignore in perforce.
Other answers have global server configurations that are global (and not per folder).
The other answers show things that might work for you, if you want one line in your view per folder times number of extensions you want to ignore in that single folder, or that provide this capability in WebSphere Studio plugins only, or provide capability for server administrators, but not available to users.
In short, I find Perforce really weak in this area. While I appreciate that those who use the Eclipse Plugin can use .p4ignore, and I think that's great, it leaves those of us that don't, out in the dark.
UPDATE: See accepted answer for new P4IGNORE capability added mid-2012.
I have found it easiest to reconcile offline work using a BASH script like this one:
#!/bin/bash
# reconcile P4 offline work, assuming P4CLIENT is set
if [ -z "$P4CLIENT" ] ; then echo "P4CLIENT is not set"; exit 1; fi
unset PWD # confuses P4 on Windows/CYGWIN
# delete filew that are no longer present
p4 diff -sd ... | p4 -x - delete
# checkout files that have been changed.
# I don't run this step. Instead I just checkout everything,
# then revert unchanged files before committing.
p4 diff -se ... | pr -x - edit
# Add new files, ignoring subversion info, EMACS backups, log files
# Filter output to see only added files and real errors
find . -type f \
| grep -v -E '(\.svn)|(/build.*/)|(/\.settings)|~|#|(\.log)' \
| p4 -x - add \
| grep -v -E '(currently opened for add)|(existing file)|(already opened for edit)'
I adapted this from this Perforce Knowledge Base article.
I'm looking for a .p4ignore like solution as well (and not one tied to a particular IDE). Thus far, the closest thing I've found is p4delta. It sounds like it will do exactly what the original poster was asking, albeit through another layer of indirection.
http://p4delta.sourceforge.net
Unfortunately, while this does seem to produce the proper list of files, I can't get "p4delta --execute" to work ("Can't modify a frozen string") and the project has not been updated in year. Perhaps others will have better luck.
If you are using the Eclipse Perforce plugin, then the plugin documentation lists several ways to ignore files.