Skip to main content
This article covers how long comparisons take and what happens when you submit a lot of them at once. It is the reference for questions like “how long should I let this run before timing out?” and “do I need to throttle my requests?”.

​
Expected time to compare

Most of the time in a comparison is spent on data transfer and file conversion, not the comparison itself. That has one consequence worth designing around: comparing PDFs is several times faster than comparing Word documents, because PDFs need less conversion work. Speeds vary with document content and server load, but these ranges are a reasonable guideline for how long a comparison takes to become ready after submission.
These are guidelines, not guarantees. Treat them as a basis for setting sensible timeouts and user expectations rather than as a service level commitment.
If comparison speed matters to your integration and you control the documents, converting to PDF before submission is the single most effective change you can make. A 100-page DOCX-to-DOCX comparison can take several times longer than the equivalent PDF-to-PDF comparison.

​
Setting timeouts

Use the table above to choose a timeout that suits the documents you actually handle, then add generous headroom for server load. A practical approach is to poll with a backoff and give up well past the expected time, surfacing a clear message to the user rather than hanging. See Viewing and sharing comparison results for the polling pattern, and the wait parameter that lets you skip polling entirely.

​
Batch jobs

You do not need to rate limit, throttle, or spread out your comparisons. If you submit a large number at once, Draftable works through them in sequence and in parallel.
Submitting a batch all at once gets it processed fastest. Deliberately spacing out submissions does not help and will usually make the whole job take longer.

​
How prioritisation works

Draftable recognises two usage patterns and prioritises them differently, automatically. Your usage pattern is detected automatically. There is no parameter to set and nothing to configure. Interactive comparisons stay responsive even while a large batch is running, and batches are worked through at a steady rate so they do not block the service for other users.

​
Batch throughput

Batch comparisons are processed in parallel, so a batch finishes far faster than the sum of its parts. At least 10 comparisons are processed in parallel in a batch job. So a batch of 100 comparisons that each take 10 seconds does not take 1,000 seconds; it should complete in under 100 seconds.
When estimating how long a bulk job will take, divide the total sequential time by at least 10. Build your progress reporting around the batch completing, not around individual comparisons finishing in a predictable order.

​
If comparisons are slower than expected

1

Check the file types

Word to Word comparisons are legitimately several times slower than PDF to PDF. Confirm you are comparing what you think you are.
2

Check the document size and page count

The times above scale with length. A document far larger than 400 pages will take proportionally longer, and may exceed your account’s page limit entirely.
3

Check how the files are supplied

If you supply a source_url, Draftable has to fetch the file first. A slow or distant host adds that fetch time to every comparison.
4

Confirm it is not actually failing

A comparison that has finished unsuccessfully is ready but failed. If your code only checks ready, a failure can look like a hang. See Handling errors and comparison failures.
5

Check the service status

If comparisons are broadly slow rather than slow for specific documents, check Draftable API status.

Creating a comparison

Viewing and sharing results

Handling errors and failures

Checking Draftable API status