Im not going to far out on a limb by saying this, but more than likely it is not updatedb that is causing your problems. Probably something else that you dont want, either a back-up application that you have not configured to your 'liking' or some security issue with your profile/systems group structure.
Another case in which it would seem that the systems memory allocation is working against the user is the scenario when one 'unknowing stacking virtual file systems'. And that is booger of problem. A 'virtual ill-logic bomb' so to speak.
It quite frequently happens to USB drives formatted in fat32 on an ext 4 system who are then transfered to zfs systems that are improperly set up with the csh shell as the man login shell. It creates the virtual recursion of "Read-File only USB file system" problem on the disk and formats/mounts the drive to vFat from fat32, which in turn creates a bad blocks sector, and extracts (virtually moves) a directory up to its parent directories level, which causes the infinite loop! The directory isn't physically at the parent's level of hierarchy. The Syntax of the csh causes is the cause of this.
*NOTE: The drive is read only on all systems but a zfs c-shell login system.
To completely disable updatedb could create ill-logic in reference to memory-allocation and 'the roll back effect'.. If you have ever had a roll back when you didnt want it, you know what I mean when two hours worth of command line scripting is Fubar-ed because you didn't allocate your your job processing into memory.
Now if you have two or more physical processors (e.g. dual core or more), and ddr3 ram, then your fine. As long as your not running heavy graphics, in which case if that powerload is causing your problems, updatedb would be last on your list. If you are trying to disguise your movements to the system for some reason then there is other ways to go about it rather than disabling updatedb, and in fact updatedb would would solidify your actions that 'nothing happen' as far the disguise to your system.
Quite frankly based on the size of the binary file /usr/bin/updatedb and considering the architecture of signal/system communication with-in the OS and that Bash is 10 times the size of is reciprocally linked shell dash or ash the asyncronous call is very inexpensive on the system.
If you are logged into the shell running sequential scripts you've written, and you are an administrator (e.g. sudo), running the following command:
~$ sudo bash
Then you probably want to create a local variable within your script (updatedb needs system priviledges, AKA root/sudo/wheel), e.g.:
# Create local variables
echo "Beginning Execution of sequence "
In which case the sequence is using STDOUT/STDIN from other shell scripts that you have written and are executing as variables with in your main script or say you have a personal or business admin package set up where you upload/download/port from cdrom or usb or whatever, that is extremely large and have personal installation scripts for them, YOU WANT TO KEEP updatedb. When the terminal shell is open, that is your main application instance. Other applications can/do run asyncronously but updatedb is one of the least expensive in terms of overall system/computing demand. Many times, especially with on the lxdm Desk Enviro's and the Lxterm (that thing is super fast), but not solely; with out adding updatedb to my scripts, the system has shot me errors that the files don't exist or that something screwy had happened. And Im like WHAT!
The shell is faster than system that it administers I guarantee you that!
In which case you would then call updatedb variable to lock the previous sequence into memory, as shown
echo "Updating local database "
echo "Exiting script two "
Do you see what Im saying? If you ask this because you are running execution speed tests i.e. Andrew Tanenbaum style than have at it. Other wise use the tool to your advantage.