swift: [SR-7703] Creating an array with 10.000 elements is slow with optimization.

Previous ID SR-7703
Radar rdar://problem/40334734
Original Reporter andreasw (JIRA User)
Type Bug

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee @eeckstein
Priority Medium

md5: a9f53d8799e79775521d84b544cb5974

is duplicated by:

Issue Description:

After #50173 and #50231 were fixed, compiling large arrays works fine without optimization, in a non-asserting build where the SILVerifier is disabled (still waiting for #50242).

Switching on -O slows down compilation again. See the attached Makefile how I create an array of 10.000 Int elements. Compiling with -O takes 16 seconds.

Here are the offending functions from perf:

+ 58,96% 0,05% swift swift [.] (anonymous namespace)::RedundantLoadElimination::run ▒
+ 57,33% 2,04% swift swift [.] (anonymous namespace)::BlockState::processStoreInst ▒
+ 50,06% 28,52% swift swift [.] llvm::DenseMapBase<llvm::SmallDenseMap<swift::LSLocation, unsigned int, 32u, llvm::DenseMa▒
+ 32,62% 2,89% swift swift [.] swift::LSLocation::isMayAliasLSLocation ▒
+ 32,01% 0,05% swift swift [.] swift::LSLocation::enumerateLSLocation ▒
+ 31,97% 0,07% swift swift [.] swift::LSLocation::enumerateLSLocations ▒
+ 21,43% 10,09% swift swift [.] swift::LSBase::hasIdenticalProjectionPath ▒
+ 18,76% 4,43% swift swift [.] swift::AliasAnalysis::alias ▒
+ 11,32% 11,25% swift swift [.] swift::ProjectionPath::computeSubSeqRelation ▒
+ 10,97% 10,95% swift swift [.] swift::ProjectionPath::hasNonEmptySymmetricDifference ▒
+ 8,96% 8,95% swift swift [.] swift::ValueEnumerator<swift::ValueBase*, unsigned long>::getIndex ▒
+ 8,49% 0,00% swift swift [.] swift::SILPassManager::runFunctionPasses ▒
+ 8,42% 0,00% swift swift [.] swift::SILPassManager::runPassOnFunction ▒
+ 6,72% 0,01% swift swift [.] llvm::DenseMapBase<llvm::SmallDenseMap<swift::LSLocation, unsigned int, 32u, llvm::DenseMa▒
+ 5,37% 5,36% swift swift [.] llvm::DenseMapBase<llvm::DenseMap<(anonymous namespace)::AliasKeyTy, swift::AliasAnalysis:▒
+ 5,35% 0,00% swift swift [.] llvm::DenseMapBase<llvm::SmallDenseMap<swift::LSLocation, unsigned int, 32u, llvm::DenseMa▒

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 27 (14 by maintainers)

Most upvoted comments

Swift version 5.11-dev (LLVM 48dba337c6a2104, Swift 823db1fc0821481)

10.000 elements: 2.9s 100.000 elements: 35.0s

Same stack trace as in https://github.com/apple/swift/issues/50243#issuecomment-1894186322

I think this can be closed, @eeckstein. Thanks for all the work involved.

Thanks for doing the experiments! We’ll never get to the C++ time because the internal implementations of Array and scalars, like Int, are much more complicated in Swift. The compiler optimizes all the complexity away, but this is at the cost of compile time.

@gonsolo can you remind me what’s the source code for this test?

It seems the attachment at the top of this issue is corrupted. Here is it again, it’s a Makefile:

SIZE=10000
SHELL:=/bin/bash

CONFIGURATION=-O

SWIFTC=swiftc

all: size time_swift time_cpp time_python

size:
	@echo "Size: $(SIZE)"
	@echo ""

time_swift: bug.swift
	@echo "Swift:"
	@time $(SWIFTC) $(CONFIGURATION) bug.swift
	@echo ""

time_cpp: bug.cc
	@echo "C++ (GCC):"
	@time g++ -c -O3 bug.cc
	@echo ""
	@echo "C++ (Clang):"
	@time clang++ -c -O3 bug.cc
	@echo ""

time_python: bug.py
	@echo "Python:"
	@time python bug.py

bug.swift: Makefile
	@echo "let x: [UInt] = [" > $@
	@LANG=C printf '0x%x, ' $$(seq $(SIZE)) >> $@
	@echo "]" >> $@

bug.cc: Makefile
	@echo "unsigned int x[] = {" > $@
	@LANG=C printf '0x%x, ' $$(seq $(SIZE)) >> $@
	@echo "};" >> $@

bug.py: Makefile
	@echo "x = [" > $@
	@LANG=C printf '0x%x, ' $$(seq $(SIZE)) >> $@
	@echo "]" >> $@

time_tuple: tuple.swift
	@time $(SWIFTC) $(CONFIGURATION) tuple.swift

.PHONY: c clean e edit r report p perf
c: clean
clean:
	rm -f bug.cc bug.py bug.swift bug bug.o tuple perf.data perf.data.old
e: edit
edit:
	vi Makefile
p: perf
perf: bug.swift
	time perf record $(SWIFTC) $(CONFIGURATION) bug.swift
	perf report

It seems to be the same issue as in https://github.com/apple/swift/issues/51712

We should probably close that one as a duplicate and keep this one open until we actually land a timing regression test, or odds are we will keep opening issues just because the stats changed without much improvement in build times.