Capacitor in RS232 level shifter. Data is strictly half-duplex
It's probably easier to understand your circuit when drawn a little differently:



simulate this circuit &ndash; Schematic created using CircuitLab
Now it is easy to see that there are three distinct functions being performed.

Communication circuit going from PIC to DB9.
Communication circuit going from DB9 to PIC.
Circuit to produce a negative power supply rail.

The upper circuit needs to transmit to the DB9 interface using RS-232 voltage values. For this, it needs both positive and negative voltage rails. But nominally, your PIC only needs a positive rail. So something extra is needed to produce the negative rail.
The lower circuit needs to receive from the DB9 interface using RS-232 voltage levels. But this is much simpler to handle and there is no need for a negative supply rail for this sub-circuit.
The negative supply rail is developed on the assumption that your DB9 interface is attached to a true RS-232 device. Normally, the DB9 TxD &quot;MARK&quot; value is a negative voltage -- somewhere between \$-3\:\textrm{V}\$ and \$-15\:\textrm{V}\$. (Hopefully, with a magnitude isn't just scraping by.) Since the DB9 must occasionally produce a &quot;MARK&quot; (stop bit, at the very least, once per byte), there will always be access to this voltage for a moment in each character's period. Diode \$D_1\$ allows this negative voltage to pass and charge \$C_1\$ to a negative voltage. This then can be used by the first circuit (the PIC TxD circuit) to produce valid negative voltage values without forcing you to add a negative voltage power supply to your PIC. It &quot;steals&quot; the negative supply from the DB9 connection, instead.
This is a serious &quot;cheat.&quot; And it cannot always work well in all circumstances. The data content itself that you receive at the PIC will affect how well it works when the PIC transmits. This is why there is a kind of balancing act here. If the capacitor is too large, then it will take time to charge up and the stop bit's MARK (and/or some data MARK values) may not be enough to get it charged up fast enough. If the capacitor is too small, then it far too quickly discharges as the PIC transmits MARKs to the DB9.
There is no guarantee that this circuit will always work in all circumstances. The DB9 TxD driver expects to see a load of between \$3\:\textrm{k}\Omega\$ and \$7\:\textrm{k}\Omega\$, memory serving. And not a load of a capacitor through a diode! The PIC RxD circuit is already loading things down as it is, too. So the circuit is making some serious assumptions about the output impedance of the DB9 TxD driving circuit.

This kind of circuit is safer to use in situations where you have a priori knowledge about the length of, and intervals between, the delays between transmissions going from the DB9 to you. This is because during the time between transmissions, the DB9 TxD line will be in the MARK state and supplying your capacitor. The higher the percentage of time that the DB9 TxD line stays in MARK state, consistent also that there aren't too long of delays between, as well, then the more certain you are that the capacitor is charged up sufficiently well for transmission in the other direction. And this may allow you to use larger capacitors, too, which then allow you to transmit data in the other direction for longer periods (or with more zero bit-value contents.)

The circuit is a hack I first saw in the 1970's as microcontrollers were first starting to roll out into the general public and RS-232 was in wide use. We had exactly two common chips for RS-232, the MC1488 and MC1489 (Jim Thompson is to blame for these burning HOT power-hogs -- see: Analog Innovations (on the WayBack machine now)) and they required separate power supply rails. All of this cost money, space, time, and so on. So a hack like this was almost a &quot;no brainer&quot; as, also, transmission rates back then were far more typically around 300 bps and almost never as high as 9600 bps. (The 9600 bps communications was pretty much reserved for very expensive Bell Telephone devices that few of us had access to.) This is because we were usually using RS-232 to communicate between a terminal (ASR-33, Diablo 1600, etc) and a modem. Not between two nearby micros. RS-232 was growing in speed rapidly as the newer, cheaper &quot;glass terminals&quot; came into use (ADM-3A kit that I built, for example) where higher speeds were useful. But even then, it was never faster than 9600 bps according to my recollection -- though I think I heard a few brags about reaching 19200 from time to time.
Speeds did rapidly increase in the early to mid 1980s, though. And the hack stuck around. But I think you are flogging a weak horse pretty hard and it is way past its code date, now. There are too many other good options to choose from that we did NOT have back then. Back then the rates were low enough (mostly) and the options few (no cheap switchers, no MAX232s, etc) and the required power and dissipation so much more too, that it could be justified from time to time. But today the speeds are so much higher and the number of really good choices so very much larger that I can't think of a good reason anymore to use this ancient technique.

Final notes. Another trick in all this is to use, if you have access to it, an RS-232 signal output line on the DB9 other than TxD. For example, there are four common signals called DTR, DSR, RTS, and CTS. (There are two others, RI and DCD, but those are more modem-required things and less likely.) If you can identify if any of these lines are outputs on your RS-232 interface and can ensure that they go into and stay in the MARK state, then you can use one of those as your negative rail (or else use them to charge that capacitor.) So this might be another option to consider.