ERROR: Steps to Avoid "Script Too Large to be Compiled" Errors [17199]

This article applies to:

E-Prime 3.0

E-Prime 2.0
E-Prime 1.x

Detail

The E-Basic compiler has a finite amount of room to store string literals (i.e. text entered between quotation marks) and object compiled code. For example, every place the script generates Object.Property = "this is the value" reduces this amount. Once this room has been used up, a "script is too large to be compiled" error occurs.

 
Many times, the design of the experiment causes a large amount of script to occur (e.g. too many unnecessary objects, objects with large amounts of text entered into their Text property). Simply changing the design of the experiment reduces the chances of running up against the compiler limit and typically makes the experiment easier to manage (see examples below).

 
The following steps can be used to avoid receiving the "script is too large to be compiled" error:

1. Upgrade to the latest version of E-Prime. There have been updates to how many of the E-Objects generate their E-Basic script, which significantly reduces the chances for the compiler error.
2. Take the time to design your experiment before implementing it. A number of the "script too large" errors can be reduced by simply changing the design of the experiment, which in turn makes the experiment easier to manage. For a list of general guidelines, please see INFO: E-Basic Style Guidelines/Recommendations [17912]
3. Ensure all List objects have their LoadMethod property set to Embedded (located on the General tab of the List's property pages).
4. When presenting a lot of text (e.g. instructions screens), attempt to store the text in a List attribute. Then, reference the attribute in the TextDisplay/SlideText object's Text property (i.e. instead of typing the text directly into the Text property). This reduces the number of string literals that must be generated.
5. Attempt to reduce the number of objects in the experiment. Keep in mind that it is very rarely necessary to create more than one object to present your stimuli. That is, unless two objects are completely different (e.g. they are collecting responses from different devices), there are very few cases where creating a new object would be preferred over using attribute references to vary a single object's properties.
6. Recycle unused E-Objects and Sub-Objects that may be taking up space. For example, with using many SlideButtons, the experiment can become large quickly. If your experiment allows it, reduce and reuse the number of Objects when you can.

Below are 2 examples that demonstrate how to avoid the "script is too large to be compiled" error.

Example 1: On trial 1 of a lexical decision task, a TextDisplay is used to present the word "dog" for 1000ms. On trial 2, a TextDisplay is used to present the word "jop" for 1500ms. Both trials collect a 1 (word) or 2 (non-word) response from the keyboard. In this situation, there is no reason to create two separate TextDisplay objects. Instead, simply create two attributes in your TrialList. One attribute holds the stimulus itself (e.g. "dog" or "jop"), while the other holds the object duration (e.g. 1000 or 1500). Reference each attribute in its corresponding property within the single TextDisplay. The TextDisplay presents the appropriate stimulus on each time for the appropriate duration.

Example 2: In the same lexical decision task, trials are broken up into two blocks. The experiment structure uses two Lists (e.g. TrialList1 and TrialList2). TrialList1 calls TrialProc1, which runs the Fixation1 object (i.e. fixation cross for 1000ms), the Stimulus1 object (i.e. stimulus that terminates upon a response), and the Feedback1 object. TrialList2 calls TrialProc2, which runs the Fixation2 object (i.e. fixation cross for 1000ms), the Stimulus2 object (i.e. stimulus that terminates upon a response), and the Feedback2 object. In this situation, the two separate Procedures are unnecessary. The Procedures themselves are identical (i.e. they both run the same number and type of objects), and the objects on each Procedure are also identical (i.e. same properties). This creates a large amount of unnecessary script. Here, we recommend that TrialList1 and TrialList2 simply call the same Procedure. The stimuli are still be split between two blocks, but use the same objects rather than two separate sets of objects.