To add an extra perspective to @Ella's answer: DES is expensive in software, and hard to implement efficiently in constant time. DES was designed with hardware in mind, so it uses operations that can be very efficiently translated to a custom circuit (e.g. bit permutations, which boil down to simple wiring), but are comparatively much more expensive in software.
A big part of DES is the "S-boxes", which are 6→4 functions. A typical DES implementation will use lookup tables, with the bit permutation merged into the tables (i.e. the output of each table is a 32-bit word, which maps the 4-bit S-box output to its permuted emplacement). Such an implementation can be observed there. Unfortunately, this means that encryption entails array accesses at indices that depend on secret data, which can lead to successful side-channel attacks (in a nutshell, these accesses "kick out" previous data from the level-1 cache in the CPU, making ulterior accesses that exercise the same cache lines slower, in a way detectable by attackers). Making a constant-time DES implementation that does not suffer from this issue requires some heavy tricks such as bitslicing, without the benefit of a parallel encryption mode (since DES and 3DES are typically used with CBC mode, not CTR). One such implementation can be seen there, and while it is constant-time, it is also three times slower than the table-based implementation, which is already quite slow by modern standards.
Triple-DES ("3DES") fixes most of the cryptanalytic issues with DES, except the 64-bit block size, which is close to allowing practical attacks; however, it also makes the performance issues three times worse.
We can thus say that DES, and its "improvement" 3DES, have a big conceptual weakness which is that they make it real hard to implement both securely and efficiently, leading to uncomfortable trade-offs (and, in practice, non-secure implementations, because implementers always favour performance, which can be measured, over security, which cannot).