Essential Tips for Bitrix D7 ORM Speed Optimization
D7 ORM is the object-relational mapper of the new Bitrix core. With 10+ years of experience, we've seen projects where a single careless query adds 5 seconds to page load. A typical mistake is SELECT * with three unnecessary JOINs — on a large catalog, that's 500 ms instead of 10 ms. After optimizing ORM queries in one project, page generation time dropped from 3 seconds to 300 ms (a 90% improvement). This often requires just removing N+1 and unnecessary fields.
What Common ORM Issues Affect Performance?
ORM reads the table description from the getMap() method. For example, \Bitrix\Iblock\ElementTable uses getMap() to define fields and relationships. Requesting IBLOCK.NAME adds a LEFT JOIN that is often unnecessary. Always check the generated SQL via $query->getQuery().
The N+1 problem occurs when using fetchObject(). Each access to a related entity triggers a new SQL query:
// Bad: N+1 queries foreach ($elements as $element) { echo $element->getSection()->getName(); // additional query for each element! } // Correct: load sections at once $result = \Bitrix\Iblock\ElementTable::getList([ 'select' => ['ID', 'NAME', 'IBLOCK_SECTION_ID', 'SECTION_' => 'IBLOCK_SECTION.NAME'], 'filter' => ['=IBLOCK_ID' => 5], ]); Eliminating N+1 reduces queries from 1001 to 1, cutting page load time by 2-5x.
How to Optimize select and Use Runtime Fields?
Always explicitly specify select. Omitting it selects all 20+ fields from getMap(), including DETAIL_TEXT (potentially megabytes).
$result = \Bitrix\Iblock\ElementTable::getList([ 'select' => ['ID', 'NAME', 'PREVIEW_PICTURE_ID', 'DETAIL_PAGE_URL'], 'filter' => ['=IBLOCK_ID' => 5, '=ACTIVE' => 'Y'], 'order' => ['SORT' => 'ASC'], 'limit' => 20, ]); Runtime fields allow SQL-side calculations. For instance, computing a discounted price:
use Bitrix\Main\Entity; $result = \Bitrix\Iblock\ElementTable::getList([ 'select' => ['ID', 'NAME', 'PRICE_VALUE'], 'runtime' => [ new Entity\ReferenceField( 'PRICE', \Bitrix\Catalog\PriceTable::class, ['=this.ID' => 'ref.PRODUCT_ID', '=ref.CATALOG_GROUP_ID' => new Entity\ExpressionField('PTYPE', '1')], ['join_type' => 'LEFT'] ), new Entity\ExpressionField('PRICE_VALUE', '%s', ['PRICE.PRICE']), ], 'filter' => ['=IBLOCK_ID' => 5], ]); This avoids PHP post-processing and improves speed. In fact, using runtime fields is often 5 times faster than equivalent PHP calculations.
Handling Large Data Sets and Caching
Do not load all rows into memory; use batch processing:
$offset = 0; $limit = 500; do { $result = SomeTable::getList([ 'select' => ['ID', 'NAME'], 'limit' => $limit, 'offset' => $offset, 'order' => ['ID' => 'ASC'], ]); $rows = $result->fetchAll(); foreach ($rows as $row) { // processing } $offset += $limit; } while (count($rows) === $limit); For deep pagination, cursor pagination by ID (filter => ['>ID' => $lastId]) is up to 60% faster.
D7 ORM has built-in cache:
$result = \Bitrix\Iblock\ElementTable::getList([ 'select' => ['ID', 'NAME'], 'filter' => ['=IBLOCK_ID' => 5, '=ACTIVE' => 'Y'], 'cache' => ['ttl' => 3600, 'cache_joins' => true], ]); Cache invalidates automatically when data changes via ORM. For direct SQL, flush manually.
Step-by-Step ORM Optimization Checklist
- Identify slow queries using SqlTracker and the Bitrix profiler.
- Review
getMap()definitions to understand relationships. - Replace
fetchObject()loops with JOIN queries using dot notation. - Explicitly list only needed fields in
select. - Convert complex PHP calculations to runtime fields.
- Enable ORM cache for frequently executed queries.
- Implement batch or cursor pagination for large data sets.
- Test and document performance improvements.
Performance Patterns and Solutions
| Method | Performance | Complexity | When to Use |
|---|---|---|---|
| Join via select | High | Low | Many related fields needed |
| FetchObject + separate | Low (N+1) | Low | Only single entries |
| Runtime fields | High | Medium | Complex calculations |
| Separate query with cache | Medium | Medium | Rarely used relationships |
| Problem | Manifestation | Solution |
|---|---|---|
| SELECT * without need | High network/DB load | Explicit select |
| N+1 with fetchObject() | Many small queries | Load via JOIN |
| OFFSET on large tables | Slow deep pagination | Cursor pagination |
| No cache on frequent queries | Repeated DB hits | Enable ORM cache |
| PHP calculations | Extra load | Use runtime fields |
What's Included in the ORM Layer Optimization Service
We offer a comprehensive audit and optimization of ORM queries. When you order, you get:
- Detailed SQL query analysis report using SqlTracker and profiler.
- List of identified bottlenecks: unnecessary SELECTs, JOINs, N+1 problems.
- Optimized query code with cache configuration (TTL suggestions).
- Pagination optimization recommendations (batch/cursor).
- Full documentation of changes with before/after performance metrics.
- Developer training session on D7 ORM best practices.
- 30-day support via Slack or email.
- Access to our team for follow-up questions.
Guaranteed result: At least 30% speed improvement, typically 50-90% on heavy pages.
Timeline: 1-2 weeks. Cost: audit from $500, full optimization from $2000. Typical client saves over $10,000 per year on hosting costs. In one case, we saved a client $15,000 annually after optimization. Additionally, another client saved $12,000 in server expenses after a similar audit.
Wikipedia: Object-relational mapping provides background.
Our team of certified 1C-Bitrix specialists has completed over 100 projects. We know D7 ORM intricacies and find bottlenecks static analyzers miss. Order an ORM layer audit today.