There is no recommended maximum number of items to put in a drop down list.
No-one can say the maximum is 7 or 12 or 200 or 10,000 and definitively say that for all scenarios, that is the maximum you should use.
There is a myth for drop down lists and menus that you should not use more than 7 +/- 2 because that's how your memory chunks things, but that's not true because of the way lists are inherently scannable - you don't have to remember all the items in a list.
The next factor is the number of items visible at any one time in the list - let's say 10 to 20 items. That seems reasonable but depends on whether the list is wide and/or covers the content underneath and how that affects the user's ability to be able to choose an item when other content is covered.
After that there's the introduction of a scrollbar and the difficulty of making a choice is increased because you only have a relatively small window view to the whole set of options. So the ratio of number of options to the number visible at any one time is the factor there.
At that point you also really start to care about how the items are sorted, so as to make the list scannable, and aid memory of where you saw an item earlier or later in the list.
So a typical scenario is choosing a country when entering an address. We're all familiar wih 200 or so items in such a list and can deal with that reasonably well most of the time, but imagine if that list wasn't sorted - it would be a horrendous task.
Unfortunately that really happens in the wild - here's a preposterous example from Hyatt Hotels asking you to choose an airline from 180+ options. Note the rediculous position in the list of "Other Airlines (Not Listed)"
Even so - when sorted, all lists are not equal - some numbers are more easily scanned than some words, especially if the numbers are sequential, and the words are unevenly distributed across the alphabetical ordering.
Once you start getting over this 200 or so mark then things get unweildy. The numbers 1 to 1000 could work, but 1000 cities around the world would be undesirable if you can only see 10 at a time and have a tiny scrollbar to manage it with.
At that point you no longer want users to interact by scrolling - the searchable option comes into play much more dominantly. There is a step change in the way the user is expected to interact at that point - the drop down list no longer is a static list, but a dynamic list showing results of a search.
If you treat the drop down as a results list rather than a list of all possible items then the sky is your limits - your entire inventory is at your fingertips. However, you need to present it as a search box (not a static list), firstly because performance issues arise as you point out, and secondly because you will always get some users who decide to scroll up and down this immense list. Such a dynamic list should show as empty when no search term is entered rather than contain all the items.
To summarise - it depends. It depends on the visual relationship between the underlying screen content and the drop down content; it depends on the scanability of the list data; it depends on the sorted state of the items and the distribution within the sort key range; and you should question whether a static list content is even desirable in the first place.
Finally - because every situation is different (and because you just should) you should A/B test a few options with users in order to verify any such assumptions, so that you can make evidence based arguments to yourself and others that yes this was the best way to do it.
I have made the assumption that only a single dropdown can be used. One way to reduce number of items in a list is to use a multi-column option - either by using the first drop down to dynamically filter the content of the second - eg continent & country, or by extending the UI to open up a more sophisticated dialog allowing you to create a way to choose an item which is much more focused on the data in your given situation. Eg using Miller columns or filters, or whatever works for your data.
It can help to think about what you could do in an ideal world, then look back at the drop down list and see how unsuitable or archaic the drop down list feels. If it feels like that, then you have realised that the drop down is not the best way to do it. If you proceed to use the drop down anyway (eg due to time/cost/toolkit constraints), then you just made a decision based on some business rules rather than on providing a good UX, and you have to live with that.
Ultimately, the best UX does not come for free. It costs money - get over it.
<select>
field will have better performance (= will be able to show more<option>
fields), than using<div>
elements; I did a demo of this here trying to render a list of 1m search results: github.com/radekstepan/coding-challenges/tree/master/apps/…